Refresh doesn't work in build 4.25.22.0

Refresh doesn't work in build 4.25.22.0

Postby Hand » Fri 07 Dec 2007 11:03

Hi,

I use refresh after insert to obtain real value of auto-increment field. I set RefreshingFields to primary key field (auto-increment) and RefreshMode=AfterInsert. This way definitely worked fine before build 22 and produced additional select in insert statement. Since build 22 additional select is not generated. I know, that I can place additional select in insert command manually, but why the old way stopped working?
Hand
 
Posts: 5
Joined: Fri 07 Dec 2007 10:53

Postby Serious » Mon 10 Dec 2007 12:23

We tested MySqlCommandBuilder and found no problems with refreshing fields. Please describe in details the problem you encountered.
Serious
 

Postby Hand » Tue 11 Dec 2007 11:15

Hi Serious.

I'm not surprised with your answer, because almost half of answers from support team sound like "we could not reproduce". I'm not going to waste my time trying describe simple issue step by step. Let's see your code:
Corelab.MySQL 4.25.21, CommandBuilder:

bool flag = A_1.Command != null;
base.RowUpdatingHandler(A_1);
if (((!flag && (A_1.Command != null)) && ((A_1.StatementType == StatementType.Update) && ((base.RefreshMode & RefreshRowMode.AfterUpdate) != RefreshRowMode.None))) || ((A_1.StatementType == StatementType.Insert) && ((base.RefreshMode & RefreshRowMode.AfterInsert) != RefreshRowMode.None)))
{
this.AddRefreshSql(A_1.Command, A_1.StatementType);
}
}

How do you think this should work? Well - in 4.25.21 this affected update command only. Let's see what was changed in 4.25.22:

if ((!flag && (A_1.Command != null)) && (((A_1.StatementType == StatementType.Update) && ((base.RefreshMode & RefreshRowMode.AfterUpdate) != RefreshRowMode.None)) || ((A_1.StatementType == StatementType.Insert) && ((base.RefreshMode & RefreshRowMode.AfterInsert) != RefreshRowMode.None))))

Now this stupid thing affects Insert statement as well.

I decided not to use your components because of some reasons:
1. Very good ideas but not such good implementation
2. Unpredictable behavior in design-time
3. Outdated and not completed documentation
4. Bad QA
5. Bad support

To say truth your products for Delphi, I used some years ago were much more stable.
Hand
 
Posts: 5
Joined: Fri 07 Dec 2007 10:53

Postby Serious » Tue 11 Dec 2007 13:33

Refresh SQL is generated only for commands that are completely generated by MySqlCommandBuilder. The commands created manually should not be updated by MySqlCommandBuilder.

There was a bug that was fixed in MyDirect .NET 4.25.22. It is explicitly listed in our history file:
History.html wrote:Fixed bug with MySqlCommandBuilder generating empty INSERT statements

Your post is quite emotional... There is a lot "we could not reproduce" answers here on forum because sometimes it is very hard to catch one use case from hundreds to reproduce a customer problem.

Regarding your list of defects in our products, you are welcome to point at exact problems, we will fix them in the nearest builds.

When submitting bug reports, please follow the guidelines from the Support.html file:
Support.html wrote: * License number for registered users
* Version of Visual Studio .NET or another IDE
* Version of MySQLDirect .NET. You can see it in Tools | MySQL | About menu of Visual Studio
* Version of your MySQL server and client
* Version of your operating system
* Describe in detail the problem
* If it is possible send small test project to reproduce the problem, including definition of your own database objects; don't use third party components
Serious
 

Postby Hand » Tue 11 Dec 2007 14:35

Serious wrote:Refresh SQL is generated only for commands that are completely generated by MySqlCommandBuilder. The commands created manually should not be updated by MySqlCommandBuilder.


Does mentioned behavior described somewhere in documentation?

Most likely you are one of the support persons, but not a programmer.
Please show code I have bolded to any programmer and ask him how it works.

Serious wrote:There was a bug that was fixed in MyDirect .NET 4.25.22. It is explicitly listed in our history file: Fixed bug with MySqlCommandBuilder generating empty INSERT statements


Why are you talking about empty insert statement while I have asked about refresh after insert?

Serious wrote:Regarding your list of defects in our products, you are welcome to point at exact problems, we will fix them in the nearest builds.


I think this way is acceptable for freeware products, you should have your own QA team, but not use your customers as beta testers.
Hand
 
Posts: 5
Joined: Fri 07 Dec 2007 10:53

Postby Serious » Tue 11 Dec 2007 16:20

MySqlCommandBuilder follows general ADO.NET rules, at usual, common behavior is not listed in our documentation. As stated in the Automatically Generating Commands MSDN Article, when associated with a DataAdapter, the DbCommandBuilder automatically generates the InsertCommand, UpdateCommand, and DeleteCommand properties of the DataAdapter if they are null references. If a Command already exists for a property, the existing Command is used.
Why are you talking about empty insert statement while I have asked about refresh after insert?
The problem that you posted is related to this fix.
Serious
 

Postby Hand » Wed 12 Dec 2007 04:47

First of all, I've asked about RefreshingFields and RefreshMode. Those properties belong to Corelab components only, but not to ADO.NET components and they are not described in Documentation. I've never asked you how insert, update or delete statements are generated if they are empty - this is not a case.

The issue relates to s**t in your code, nothing more.

So, my conclusions - you either don't understand or don't know product you are talking about. Please stop to play games with me. This is exactly what I call BAD and UNSKILLED support.
Hand
 
Posts: 5
Joined: Fri 07 Dec 2007 10:53

Postby Serious » Wed 12 Dec 2007 12:16

RefreshingFields and RefreshMode options are not standalone features, they work on top of ADO.NET architecture affecting insert/update/delete commands generation. Commands generation completely follows standard interfaces and behavior, and our additional features conform to these rules.

Regarding the offtopic discussion. Our answers are quite competent. If we make a mistake we always acknowledge this. In the current case the code is correct, and it works as it should do. Some bugs may happen from time to time as they are an intrinsic aspect of software development.

If you have any other bug reports, you can post them, otherwise this theme will be closed as an offtopic.
Serious
 

Postby Zero-G. » Thu 13 Dec 2007 08:44

@HAND

As I can see, you have posted 4 comments, they seems to bee all in this Topic, so it seems you don't have any personal experience with the support.
Why are you so emotional? - The support of CRLab is great & they do know a lot of the whole ADO.NET Architecture.
I think you should come down and try to solve your problem hand in hand with the CRLab Team. - NO PROGRAM IS PERFECT! - Even not yours & so please be more friendly. This is not the way of talking in an official Forum
Zero-G.
 
Posts: 390
Joined: Sat 09 Dec 2006 12:20

Postby Hand » Fri 14 Dec 2007 05:35

Well guys,

Do you agree that (false && true) = false? And (false && (something)) = false? So AddRefreshSql will never be called.

That's what you call "Correct code".

I'm not going to discuss any issue regarding MyDirect anymore, so you can close topic.
Hand
 
Posts: 5
Joined: Fri 07 Dec 2007 10:53

Postby Serious » Fri 14 Dec 2007 12:21

The code snippet you provided in the previous post has nothing to do with our algorithms. Here is an example of code flow that reflects the actual state of things:
Code: Select all
class Program {

   class Arg {

     public object Command;
   }

   static void Action(Arg obj) {

     obj.Command = new object();
   }

   static void Test(Arg A_1) {

     bool flag = A_1.Command != null;
     Action(A_1);
     if (!flag && A_1.Command != null)
       Console.WriteLine("OK");
     else
       Console.WriteLine("Error");
   }

   static void Main(string[] args) {

     Test(new Arg());
   }
}
No existing problem was found, so we close this theme as an offtopic discussion.
Serious
 


Return to dotConnect for MySQL