FoxPro Programming
False vs Not Populated Logical Field
Gravatar is a globally recognized avatar based on your email address. False vs Not Populated Logical Field
  n/a
  All
  Jul 25, 2014 @ 06:02am
Hello,

Please can anyone let me know if there is a way to tell the difference between a logical field in a free table that has a "blank" value instead of a value of .F. in code? The field is not NULLable.

To clarify I can see the difference when I BROWSE the table but unsure in code.

Response really appreciated. I am against the clock on this one...

Thanks,
Steve

Gravatar is a globally recognized avatar based on your email address. Re: False vs Not Populated Logical Field
  Rick Strahl
  Steve W
  Jul 25, 2014 @ 10:24am
Steve,

Uhm - no. That's the point of using NULLs. If you need to determine non-set state then you need to use NULL values to indicate that. WIth other types you can simulate NULL behavior, (ie. -1 for numbers maybe or "NULL" for strings) but with a bool there are only two values and hence there's no way to do this.

If you don't want to use a DBC for NULL support or simply don't want to use NULLS (which I also like to avoid because they make a lot of things more difficult in queries) you might want to use a numeric field and -1,0,1 for the three states instead.

+++ Rick ---



Hello,

Please can anyone let me know if there is a way to tell the difference between a logical field in a free table that has a "blank" value instead of a value of .F. in code? The field is not NULLable.

To clarify I can see the difference when I BROWSE the table but unsure in code.

Response really appreciated. I am against the clock on this one...

Thanks,
Steve




Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: False vs Not Populated Logical Field
  n/a
  Rick Strahl
  Jul 25, 2014 @ 10:45am
Hi Rick,

Thanks for your reply.

I understand bools are only True / False. It is an old system and I needed to try and determine if the field has had False (.F.) written to it or not in order to apply a data fix for some other info. There must be some internal difference within the actual .dbf file because as I said, when I BROWSE it I can see the difference.

I just figured out some other business logic to overcome the problem in this case anyway, but it would still be interesting to know what goes on under the hood.

Cheers,
Steve


Steve,

Uhm - no. That's the point of using NULLs. If you need to determine non-set state then you need to use NULL values to indicate that. WIth other types you can simulate NULL behavior, (ie. -1 for numbers maybe or "NULL" for strings) but with a bool there are only two values and hence there's no way to do this.

If you don't want to use a DBC for NULL support or simply don't want to use NULLS (which I also like to avoid because they make a lot of things more difficult in queries) you might want to use a numeric field and -1,0,1 for the three states instead.

+++ Rick ---



Hello,

Please can anyone let me know if there is a way to tell the difference between a logical field in a free table that has a "blank" value instead of a value of .F. in code? The field is not NULLable.

To clarify I can see the difference when I BROWSE the table but unsure in code.

Response really appreciated. I am against the clock on this one...

Thanks,
Steve




Gravatar is a globally recognized avatar based on your email address. Re: False vs Not Populated Logical Field
  n/a
  Steve W
  Jul 25, 2014 @ 01:13pm
Try, isblank(<name_of_field>)


Hi Rick,

Thanks for your reply.

I understand bools are only True / False. It is an old system and I needed to try and determine if the field has had False (.F.) written to it or not in order to apply a data fix for some other info. There must be some internal difference within the actual .dbf file because as I said, when I BROWSE it I can see the difference.

I just figured out some other business logic to overcome the problem in this case anyway, but it would still be interesting to know what goes on under the hood.

Cheers,
Steve


Steve,

Uhm - no. That's the point of using NULLs. If you need to determine non-set state then you need to use NULL values to indicate that. WIth other types you can simulate NULL behavior, (ie. -1 for numbers maybe or "NULL" for strings) but with a bool there are only two values and hence there's no way to do this.

If you don't want to use a DBC for NULL support or simply don't want to use NULLS (which I also like to avoid because they make a lot of things more difficult in queries) you might want to use a numeric field and -1,0,1 for the three states instead.

+++ Rick ---



Hello,

Please can anyone let me know if there is a way to tell the difference between a logical field in a free table that has a "blank" value instead of a value of .F. in code? The field is not NULLable.

To clarify I can see the difference when I BROWSE the table but unsure in code.

Response really appreciated. I am against the clock on this one...

Thanks,
Steve





Gravatar is a globally recognized avatar based on your email address. Re: False vs Not Populated Logical Field
  Rick Strahl
  Steve W
  Jul 27, 2014 @ 11:49pm

What you 'see' as a blank value in a browse window is a bug in FoxPro (or at the very least a side effect that doesn't reflect the actual underlying value). Anything you do to that value - TYPE(), VARTYPE(), EVAL(), ISBLANK(), ISNULL() - will return values that indicate that the uninitialized boolean value is actually .F.

NULLs or a different type is the only way to offer an 'uninitialized' state to a logical value.

+++ Rick ---



Hi Rick,

Thanks for your reply.

I understand bools are only True / False. It is an old system and I needed to try and determine if the field has had False (.F.) written to it or not in order to apply a data fix for some other info. There must be some internal difference within the actual .dbf file because as I said, when I BROWSE it I can see the difference.

I just figured out some other business logic to overcome the problem in this case anyway, but it would still be interesting to know what goes on under the hood.

Cheers,
Steve


Steve,

Uhm - no. That's the point of using NULLs. If you need to determine non-set state then you need to use NULL values to indicate that. WIth other types you can simulate NULL behavior, (ie. -1 for numbers maybe or "NULL" for strings) but with a bool there are only two values and hence there's no way to do this.

If you don't want to use a DBC for NULL support or simply don't want to use NULLS (which I also like to avoid because they make a lot of things more difficult in queries) you might want to use a numeric field and -1,0,1 for the three states instead.

+++ Rick ---



Hello,

Please can anyone let me know if there is a way to tell the difference between a logical field in a free table that has a "blank" value instead of a value of .F. in code? The field is not NULLable.

To clarify I can see the difference when I BROWSE the table but unsure in code.

Response really appreciated. I am against the clock on this one...

Thanks,
Steve







Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: False vs Not Populated Logical Field
  n/a
  Rick Strahl
  Jul 28, 2014 @ 01:04am
Thanks for the replies guys.

It turns out that ISBLANK() actually does the trick...

i.e. If the field is "populated" with either TRUE, or FALSE then ISBLANK() returns FALSE. If has not been "populated" then it returns TRUE.

Cheers,
Steve

What you 'see' as a blank value in a browse window is a bug in FoxPro (or at the very least a side effect that doesn't reflect the actual underlying value). Anything you do to that value - TYPE(), VARTYPE(), EVAL(), ISBLANK(), ISNULL() - will return values that indicate that the uninitialized boolean value is actually .F.

NULLs or a different type is the only way to offer an 'uninitialized' state to a logical value.

+++ Rick ---



Hi Rick,

Thanks for your reply.

I understand bools are only True / False. It is an old system and I needed to try and determine if the field has had False (.F.) written to it or not in order to apply a data fix for some other info. There must be some internal difference within the actual .dbf file because as I said, when I BROWSE it I can see the difference.

I just figured out some other business logic to overcome the problem in this case anyway, but it would still be interesting to know what goes on under the hood.

Cheers,
Steve


Steve,

Uhm - no. That's the point of using NULLs. If you need to determine non-set state then you need to use NULL values to indicate that. WIth other types you can simulate NULL behavior, (ie. -1 for numbers maybe or "NULL" for strings) but with a bool there are only two values and hence there's no way to do this.

If you don't want to use a DBC for NULL support or simply don't want to use NULLS (which I also like to avoid because they make a lot of things more difficult in queries) you might want to use a numeric field and -1,0,1 for the three states instead.

+++ Rick ---



Hello,

Please can anyone let me know if there is a way to tell the difference between a logical field in a free table that has a "blank" value instead of a value of .F. in code? The field is not NULLable.

To clarify I can see the difference when I BROWSE the table but unsure in code.

Response really appreciated. I am against the clock on this one...

Thanks,
Steve







Gravatar is a globally recognized avatar based on your email address. Re: False vs Not Populated Logical Field
  n/a
  Steve W
  Jul 28, 2014 @ 01:17pm
Interesting -- I never knew about isblank(). It is not a behavior I would want to count on, though.


Thanks for the replies guys.

It turns out that ISBLANK() actually does the trick...

i.e. If the field is "populated" with either TRUE, or FALSE then ISBLANK() returns FALSE. If has not been "populated" then it returns TRUE.

Cheers,
Steve

What you 'see' as a blank value in a browse window is a bug in FoxPro (or at the very least a side effect that doesn't reflect the actual underlying value). Anything you do to that value - TYPE(), VARTYPE(), EVAL(), ISBLANK(), ISNULL() - will return values that indicate that the uninitialized boolean value is actually .F.

NULLs or a different type is the only way to offer an 'uninitialized' state to a logical value.

+++ Rick ---



Hi Rick,

Thanks for your reply.

I understand bools are only True / False. It is an old system and I needed to try and determine if the field has had False (.F.) written to it or not in order to apply a data fix for some other info. There must be some internal difference within the actual .dbf file because as I said, when I BROWSE it I can see the difference.

I just figured out some other business logic to overcome the problem in this case anyway, but it would still be interesting to know what goes on under the hood.

Cheers,
Steve


Steve,

Uhm - no. That's the point of using NULLs. If you need to determine non-set state then you need to use NULL values to indicate that. WIth other types you can simulate NULL behavior, (ie. -1 for numbers maybe or "NULL" for strings) but with a bool there are only two values and hence there's no way to do this.

If you don't want to use a DBC for NULL support or simply don't want to use NULLS (which I also like to avoid because they make a lot of things more difficult in queries) you might want to use a numeric field and -1,0,1 for the three states instead.

+++ Rick ---



Hello,

Please can anyone let me know if there is a way to tell the difference between a logical field in a free table that has a "blank" value instead of a value of .F. in code? The field is not NULLable.

To clarify I can see the difference when I BROWSE the table but unsure in code.

Response really appreciated. I am against the clock on this one...

Thanks,
Steve









--- Kevin

Gravatar is a globally recognized avatar based on your email address. Re: False vs Not Populated Logical Field
  n/a
  Kevin Emmrich
  Jul 28, 2014 @ 02:57pm
It works and you can count on it.
It's all right there in the help.


Interesting -- I never knew about isblank(). It is not a behavior I would want to count on, though.


Thanks for the replies guys.

It turns out that ISBLANK() actually does the trick...

i.e. If the field is "populated" with either TRUE, or FALSE then ISBLANK() returns FALSE. If has not been "populated" then it returns TRUE.

Cheers,
Steve

What you 'see' as a blank value in a browse window is a bug in FoxPro (or at the very least a side effect that doesn't reflect the actual underlying value). Anything you do to that value - TYPE(), VARTYPE(), EVAL(), ISBLANK(), ISNULL() - will return values that indicate that the uninitialized boolean value is actually .F.

NULLs or a different type is the only way to offer an 'uninitialized' state to a logical value.

+++ Rick ---



Hi Rick,

Thanks for your reply.

I understand bools are only True / False. It is an old system and I needed to try and determine if the field has had False (.F.) written to it or not in order to apply a data fix for some other info. There must be some internal difference within the actual .dbf file because as I said, when I BROWSE it I can see the difference.

I just figured out some other business logic to overcome the problem in this case anyway, but it would still be interesting to know what goes on under the hood.

Cheers,
Steve


Steve,

Uhm - no. That's the point of using NULLs. If you need to determine non-set state then you need to use NULL values to indicate that. WIth other types you can simulate NULL behavior, (ie. -1 for numbers maybe or "NULL" for strings) but with a bool there are only two values and hence there's no way to do this.

If you don't want to use a DBC for NULL support or simply don't want to use NULLS (which I also like to avoid because they make a lot of things more difficult in queries) you might want to use a numeric field and -1,0,1 for the three states instead.

+++ Rick ---



Hello,

Please can anyone let me know if there is a way to tell the difference between a logical field in a free table that has a "blank" value instead of a value of .F. in code? The field is not NULLable.

To clarify I can see the difference when I BROWSE the table but unsure in code.

Response really appreciated. I am against the clock on this one...

Thanks,
Steve









Gravatar is a globally recognized avatar based on your email address. Re: False vs Not Populated Logical Field
  Rick Strahl
  Steve W
  Jul 28, 2014 @ 07:31pm
I'd like to understand how you get the logical value into this state in the first place.

If I do this:

CREATE TABLE temp ( tst L)
APPEND BLANK
? tst && .F.
? ISBLANK("tst") && .F.

ISBLANK() returns false as it should. That's about as 'empty' as a logical value can be.
So if that's not it, how do you create what you call an empty logical value?

+++ Rick ---


Thanks for the replies guys.

It turns out that ISBLANK() actually does the trick...

i.e. If the field is "populated" with either TRUE, or FALSE then ISBLANK() returns FALSE. If has not been "populated" then it returns TRUE.

Cheers,
Steve

What you 'see' as a blank value in a browse window is a bug in FoxPro (or at the very least a side effect that doesn't reflect the actual underlying value). Anything you do to that value - TYPE(), VARTYPE(), EVAL(), ISBLANK(), ISNULL() - will return values that indicate that the uninitialized boolean value is actually .F.

NULLs or a different type is the only way to offer an 'uninitialized' state to a logical value.

+++ Rick ---



Hi Rick,

Thanks for your reply.

I understand bools are only True / False. It is an old system and I needed to try and determine if the field has had False (.F.) written to it or not in order to apply a data fix for some other info. There must be some internal difference within the actual .dbf file because as I said, when I BROWSE it I can see the difference.

I just figured out some other business logic to overcome the problem in this case anyway, but it would still be interesting to know what goes on under the hood.

Cheers,
Steve


Steve,

Uhm - no. That's the point of using NULLs. If you need to determine non-set state then you need to use NULL values to indicate that. WIth other types you can simulate NULL behavior, (ie. -1 for numbers maybe or "NULL" for strings) but with a bool there are only two values and hence there's no way to do this.

If you don't want to use a DBC for NULL support or simply don't want to use NULLS (which I also like to avoid because they make a lot of things more difficult in queries) you might want to use a numeric field and -1,0,1 for the three states instead.

+++ Rick ---



Hello,

Please can anyone let me know if there is a way to tell the difference between a logical field in a free table that has a "blank" value instead of a value of .F. in code? The field is not NULLable.

To clarify I can see the difference when I BROWSE the table but unsure in code.

Response really appreciated. I am against the clock on this one...

Thanks,
Steve










Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: False vs Not Populated Logical Field
  n/a
  Rick Strahl
  Jul 29, 2014 @ 01:04am
Hi Rick,

In the example below VFP is interpreting the string passed into ISBLANK(). Pass the fieldname without quotes instead.

Thanks again to others for their replies. I completely agree that this isn't something I would want to typically rely on but still an interesting "feature".

Cheers,
Steve


I'd like to understand how you get the logical value into this state in the first place.

If I do this:

CREATE TABLE temp ( tst L)
APPEND BLANK
? tst && .F.
? ISBLANK("tst") && .F.

ISBLANK() returns false as it should. That's about as 'empty' as a logical value can be.
So if that's not it, how do you create what you call an empty logical value?

+++ Rick ---


Thanks for the replies guys.

It turns out that ISBLANK() actually does the trick...

i.e. If the field is "populated" with either TRUE, or FALSE then ISBLANK() returns FALSE. If has not been "populated" then it returns TRUE.

Cheers,
Steve

What you 'see' as a blank value in a browse window is a bug in FoxPro (or at the very least a side effect that doesn't reflect the actual underlying value). Anything you do to that value - TYPE(), VARTYPE(), EVAL(), ISBLANK(), ISNULL() - will return values that indicate that the uninitialized boolean value is actually .F.

NULLs or a different type is the only way to offer an 'uninitialized' state to a logical value.

+++ Rick ---



Hi Rick,

Thanks for your reply.

I understand bools are only True / False. It is an old system and I needed to try and determine if the field has had False (.F.) written to it or not in order to apply a data fix for some other info. There must be some internal difference within the actual .dbf file because as I said, when I BROWSE it I can see the difference.

I just figured out some other business logic to overcome the problem in this case anyway, but it would still be interesting to know what goes on under the hood.

Cheers,
Steve


Steve,

Uhm - no. That's the point of using NULLs. If you need to determine non-set state then you need to use NULL values to indicate that. WIth other types you can simulate NULL behavior, (ie. -1 for numbers maybe or "NULL" for strings) but with a bool there are only two values and hence there's no way to do this.

If you don't want to use a DBC for NULL support or simply don't want to use NULLS (which I also like to avoid because they make a lot of things more difficult in queries) you might want to use a numeric field and -1,0,1 for the three states instead.

+++ Rick ---



Hello,

Please can anyone let me know if there is a way to tell the difference between a logical field in a free table that has a "blank" value instead of a value of .F. in code? The field is not NULLable.

To clarify I can see the difference when I BROWSE the table but unsure in code.

Response really appreciated. I am against the clock on this one...

Thanks,
Steve










© 1996-2024