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
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
West Wind Technologies
Making waves on the Web
from Maui
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
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
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
West Wind Technologies
Making waves on the Web
from Maui
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
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
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
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
West Wind Technologies
Making waves on the Web
from Maui
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