URGENT BUG

[ben]

Hello,

I was using 5.00.1.7 without problems until I updated to latest 5.10 and now i have an error message:

EDatabaseError: Cannot access field 'prepaymoney' as type Float

prepaymoney is decimal 6.2

is it necessary when you fix something to destroy other things working? Really, I cant understand this.

Thanks god Im keeping an complete file list of all mydac versions so I can backward in case of problem.

I would suggest other users doing the same.

[swierzbicki]

Hi,

5.0.1.7 introduced these kinds of bugs... it looks 5.0.10.9 correct them !
I had a similar issue with an persistant field :
- build 5.0.1.7 created an LargeInt field (taht was wrong and I didn't noticed)
- build 5.10.9 raised an error with something like : LargeInt filed found, expected Boolean field. Removing and recreating this persistent fields solves my issue.

[ben]

build is the one I had, downloaded yesterday and I cant use it without this fix.

Any CrLab staff around ?

[Antaeus]

Hello,
I was using 5.00.1.7 without problems until I updated to latest 5.10 and now i have an error message:
EDatabaseError: Cannot access field 'prepaymoney' as type Float
prepaymoney is decimal 6.2
is it necessary when you fix something to destroy other things working? Really, I cant understand this.
Thanks god Im keeping an complete file list of all mydac versions so I can backward in case of problem.
I would suggest other users doing the same.

I tried to create a simple application that works with a field of such type using MyDAC 5.00.1.7, then I installed MyDAC 5.10.0.9 and tested this application. I did not find any problems.
What should I do to reproduce the problem? When does the problem appear? A small sample and a script to create the table that reproduce this problem would help us very much. If you have such sample, you can send it to evgeniyd*crlab*com.

[Antaeus]

Hi,

5.0.1.7 introduced these kinds of bugs... it looks 5.0.10.9 correct them !
I had a similar issue with an persistant field :
- build 5.0.1.7 created an LargeInt field (taht was wrong and I didn't noticed)
- build 5.10.9 raised an error with something like : LargeInt filed found, expected Boolean field. Removing and recreating this persistent fields solves my issue.

Corresponding to your request by email we extended ability to detect MySQL boolean constants for queries like:

Code: Select all

Set @SumA = 999 ,
  @SumB = 1000;
 Select
 Case When @SumA = @SumB then True else False End as SumOK

In MyDAC 5.10.0.9 this field is described as TBooleanField instead of TLargeintField. That is why you had to recreate some fields in design time.

[swierzbicki]

Hi Antaeus,

Yes you are right, I've asked for this ! (BTW thank you for having implementing it). This is working fine.

I was talking about something different : as I wouldn't stop my development, I have replaced the True / False keywords with 1 / 0.
You can see the code below :

Code: Select all

Set @SumA = 999 , 
  @SumB = 1000; 
 Select 
 Case When @SumA = @SumB then 1 else 0 End as SumOK

With Build 5.1.0.7 SumOK field is treated as an LargeInt
Now, with Build 5.1.0.9 SumOK field is treated as an Boolean

Is this expected ?

Ps : 5.0.1.7 didn't introduced such bug... and I was speaking too quick ! Sorry

[Antaeus]

Is this expected ?

No it does not. We performed some additional tests, and it looks like there is no way to determine what constants were used for this field:

Code: Select all

Select Case When @SumA = @SumB then 1 else 0 End as SumOK

or

Code: Select all

Select Case When @SumA = @SumB then True else False End as SumOK

I think, we have to rollback this modifiation in the next build.

[swierzbicki]

Ok ! It is sad, but safer...
Will it not works if we cast the whole thing ? (either in boolean or integer)

[ben]

I'll prepare a demo soon.