Refresh doesn't work in build 4.25.22.0
Refresh doesn't work in build 4.25.22.0
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?
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?
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.
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.
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:
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:
There was a bug that was fixed in MyDirect .NET 4.25.22. It is explicitly listed in our history file:
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.History.html wrote:Fixed bug with MySqlCommandBuilder generating empty INSERT statements
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
Does mentioned behavior described somewhere in documentation?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.
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.
Why are you talking about empty insert statement while I have asked about refresh after insert?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
I think this way is acceptable for freeware products, you should have your own QA team, but not use your customers as beta testers.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.
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.
The problem that you posted is related to this fix.Why are you talking about empty insert statement while I have asked about refresh after insert?
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.
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.
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.
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.
@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
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
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:No existing problem was found, so we close this theme as an offtopic discussion.
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());
}
}