Still problem with Boolean

[JohnGalt]

Well, I guess it's not really a *problem*, but it did break previous behaviour, which I think is a problem.

I used to (and still, until I can do a rewrite of my entire app, do) use TinyInt(1) fields to represent booleans. Previously, checkboxes that saved to these saved as 1's. I know you changed these to be "Boolean" fields, and have a property that allows you to call these integer fields. However, when I do this, checked checkboxes are now saving as "-1", instead of "1", which was the previous behaviour. I realize that I can change my fields to "TinyInt(1) UNSIGNED", but again, I shouldn't have to. Making this database structure change at all my clients' will be a huge hassle. Can you please change this behaviour so that it works as before, if you've elected not to use the "Boolean" field type?

Thanks.

[Ikar]

Since MyDAC 3.10.1.7 TinyInt(1) fields are represented as TBooleanField. To solve problems declare these fields as TinyInt(4) or set TCustomMyDataSet.Options.EnableBoolean := False

[JohnGalt]

If you re-read my original post, you'll see that I *did* set enableBoolean to false, but it's still saving it as -1, instead of 1 if it's a signed TinyInt. It used to save it as 1. Can you please restore this behaviour?

Thanks.
I.

[JohnGalt]

Actually, I went ahead and re-wrote my code to take advantage of EnableBoolean, and if I look at my raw database, it still saves a "true" result as -1. This seems wrong to me. I've always looked at true as 1, and false as 0. Is there a particular reason why you save a Boolean "true" result as a -1 in a TinyInt(1) field?

Thanks.

[JohnGalt]

The reason this is a problem for me is that throught my program I have SQL statements that get records based on the value of these TinyInt fields.

So throughout my program, I have queries that look like:
SELECT * FROM table where tinyint_field = 1

Now, because you've changed the behavior even when BooleanEnabled is true, I have to find everywhere I do a search on a boolean field and change it to

SELECT * from table where tinyint_field IS NOT NULL and tinyint_field != 0

This is because I apparently can't count on CoreLab to have its components keep consistent behaviour from one release to the next. If I change everything to

SELECT * from table where tinyint_field = -1

how do I know you won't change the value of a boolean true in your next release?

Can you please give me some guidelines on your policy around this, and what I can expect in the future?

As I say, I *love* your component, and it's helped me a lot, but I expect you to make your releases backwards compatible. From my perspective, BooleanEnabled should have been defaulted to false, rather than true, so it wouldn't break any existing applications. In addition, it should have saved TRUE Booleans to a TinyInt(1) as a 1, rather than a -1, so it wouldn't break existing applications. Do you disagree?

Thanks.

[Ikar]

Please specify in what way do you fill and retrieve value of these TinyInt fields?

[JohnGalt]

I'm using DevExpress's ExpressEdit Controls, specificially in this case the checkbox control.

It's bound to my TinyInt(1) field, and uses Boolean types, with no Gray type allowed.

[Ikar]

Please check a value of TdxDBGridCheckColumn.ValueChecked property.

[JohnGalt]

ValueChecked = true, Type = boolean
ValueUnchecked = false, Type = boolean
ValueGreyed = (NULL), Type = NULL

[Ikar]

Try to set
ValueChecked = 1, Type = integer
ValueUnchecked = 0, Type = integer


It will allow to avoid the problem but doesn't clarify as before it was possible to set "1" for "True".
From the point of view of VCL (see _VarToInteger, unit Variants) for True the correct value is "-1".

[JohnGatl]

I'm not sure I understand.

My understanding is that you have arbitrarily established a TinyInt(1) as a Boolean in MySQL. This is not a native MySQL type, and the way you've chosen to implement it breaks anything that was written before you made this change. You've made the default behaviour the opposite of what it used to be (that is, you have to explicitly change all your components if you want it to work the old way, rather than requiring people to change their components if they want it to work the new way).

Does your component not sit between the DevExpress component and MySQL? Can you not change the way that your Boolean gets written so that it converts any non-zero value to a 1? I guess my problem is that everything was working fine before you made this change, and now I'm spending way too much time trying to fix what wasn't broken.

I appreciate your trying to help, and that you may feel that DevExpress is the problem here, and that perhaps nobody else has this problem, but it's made me much less confident in the MySQL components. I'll try your alternative solution, but I believe I've already tried that, and it didn't work. I'll let you know.

[JohnGalt]

Unfortunately, this does not seem to work.

The moment I move off of the checkbox after clicking it, it reverts to empty. Changing it back to Boolean/True/False works, but it's obviously now setting it -1.

Any other possible solutions?

Thanks.

[Ikar]

> This is not a native MySQL type, and the way you've chosen to implement it
> breaks anything that was written before you made this change.

It was before MySQL 4.1.0 release. Since this version BIT (BOOL, BOOLEAN) was added to the list of types that is synonym of TinyInt(1). By numerous requests of our users we supported it.

> Can you not change the way that your Boolean gets written so
> that it converts any non-zero value to a 1? I guess my problem
> is that everything was working fine before you made this change,
> and now I'm spending way too much time trying to fix what wasn't broken.

We try to clear in what current behaviour with EnableBoolean = False differs from the old we haven't succeeded yet.

A value for TSmallIntField can be assigned through TIntegerField.Value: LongInt, TField.AsInteger and TField.AsBoolean. At first two cases a value is set explicitly, but at the last one through VCL _VarFromBool and _VarToInteger functions which assume for True value "-1". We haven't got sources of QuantumGrid and we are unable to check in what way for TSmallIntField it can be possible to set True as "1" and what
prevents this method to work now.

Or I understood you incorrectly and you would like the old behaviour to remain with EnableBoolean = True?

> Any other possible solutions?

If we could find out what is changed for the method of storing in TSmallIntField boolean values we'll give back the old behaviour.

[JohnGalt]

I really appreciate your patience with this issue.

It was before MySQL 4.1.0 release. Since this version BIT (BOOL, BOOLEAN) was added to the list of types that is synonym of TinyInt(1). By numerous requests of our users we supported it.

Ah...I'm still using v4.0.x, so didn't realize that this had changed in 4.1.x. That at least explains your motivation for the change - I had no idea. I should have made it clear that I'm using 4.0.x, although I have no idea if that affects the results.

Or I understood you incorrectly and you would like the old behaviour to remain with EnableBoolean = True?

I'm sorry I haven't made myself clear. I now understand why you made the change you did, but the first rule of component evolution should be "do no harm". So, if you introduce a new behaviour like forcing TinyInt(1)'s to be Booleans, that should not be the *default* behaviour of the new component. The default behaviour of the components should be the way they've always worked (in which TinyInt(1)'s were treated like SmallInts). If you wanted the new Boolean behaviour, you should have to set it to "true". That way, for anyone recompiling with the newest components, none of their applications would break.

The major reason that this is a big deal for me is that it means that I either have to go to all 50 of my clients and change their databases from TinyInt(1)'s to TinyInt(4)'s, or I have to completely regression test every part of the program compiled with the latest version of your components to make sure I haven't missed setting a stray dataset to EnableBoolean = false (which is why I think this should have been the default behaviour of the new component).

Anyways, I appreciate the time you've spent on this, but I guess I'll just have to work around it, unless there's something else you think I could do to help you figure it out.

[Ikar]

> I now understand why you made the change you did, but the first rule of
> component evolution should be "do no harm".

You are right, in future we will try to consider similar changes more attentively.