isblank() in post

[madtowng]

I am trying to post a salesperson's ID from a customer table to the salesID in an order table.

For the purpose of this question, I will name the tables customer and orders, with orders being the master table and customers being the transaction table.

I have two possiblities for the salesID to be posted.
1. the orders->pickup_date is between customer->from_date and customer->until_date.

2. the order->pickup_date >= customer->from_date and customer->until_date is blank.

The problem I am having is isblank(@customer->until_date) and isblank("@customer->untildate") both end up as an invalid or incomplete expression.

Does someone know the trick to getting isblank() to work on a transaction table date field ?

Thanks much,

Gregg

[Stan Mathews]

Re: isblank() in post

Doesn't appear to want to cooperate. You could use

alltrim(cdate(@customer->untildate)) = ""

[madtowng]

Re: isblank() in post

Thank you Stan.
That seems to have done the trick.

[jkletrovets]

Re: isblank() in post

Just as an additional method......

I frequently use the following on date field processing:

Customer->untildate={ / / }

The above has 2 spaces between the slashes and 4 spaces after the last slash.

I also have had problems using isblank (not just date fields)

My foolproof code on character fields is:

len(alltrim(Field1))=0

Regards,

Jeff

[G Gabriel]

Re: isblank() in post

Customer->untildate={ / / }

If you hate typing, as I much as I do, you could simply use:

Customer->untildate={}

[csda1]

Re: isblank() in post

Hi Jeff,

I frequently use the following on date field processing:

Customer->untildate={ / / }

The above has 2 spaces between the slashes and 4 spaces after the last slash.

I also have had problems using isblank (not just date fields)

My foolproof code on character fields is:

len(alltrim(Field1))=0

For reasons that I was never able to ascertain, sometimes Alpha has effectively a { / / } as a blank date, and sometimes { } as a blank date. They should be identical, but in a few cases, they did not equate. So I always used for a comparison (similar to Stan's, but a very little bit faster by using TRIM() ),

trim(cdate(@customer->untildate))==""

which always worked. For character fields, I always use this comparison

trim(charactervalueorField)==""

which, by eliminating the len() function and using trim() instead of alltrim() should also be a tiny bit faster, but I haven't run extensive tests, and will probably be almost immeasurable in speed improvement.

[jkletrovets]

Re: isblank() in post

For reasons that I was never able to ascertain, sometimes Alpha has effectively a { / / } as a blank date, and sometimes { } as a blank date. They should be identical, but in a few cases, they did not equate. So I always used for a comparison (similar to Stan's, but a very little bit faster by using TRIM() ),
trim(cdate(@customer->untildate))==""

which always worked. For character fields, I always use this comparison
trim(charactervalueorField)==""

which, by eliminating the len() function and using trim() instead of alltrim() should also be a tiny bit faster, but I haven't run extensive tests, and will probably be almost immeasurable in speed improvement.

Hey Ira...thanks for the further viewpoint. My using { / / } is a holdover from my Fox 2.6 days (once I figured out IsBlank is not always reliable in Alpha).

From your examples, why do you use "=="? Once again, from my Fox days....I just convert that to "Absolutley Equals" in my mind....I was curious what your reasons are for using that instead of just the "="?

BTW, on a whole differenct subject...you have definitely turned me into a UDF fanatic. Just wanted to say thanks for your prominent viewpoint on that here on the message board......the benefits are many.....as you well know. :)

Regards,

Jeff

[csda1]

Re: isblank() in post

Hi Jeff,

From your examples, why do you use "=="? Once again, from my Fox days....I just convert that to "Absolutley Equals" in my mind....I was curious what your reasons are for using that instead of just the "="?

The double equals (which I read as "is exactly equals" - PO-TAY-TOES, PO-TAH-TOES :D ) is because a single equals is not case-sensitive and implicitly trims the left and right parameters of the equals comparisons.

In some cases this is OK if you are aware of the conversions and accept them, however, I like my code to be 100% definitive in it's meaning (to me and others) and never unintentionally have another meaning.

So

?IF("ABC"="abc ",.t.,.f.)
= .T.
?IF(("ABC"+" ")="abc ",.t.,.f.)
= .T.
varvalue=" "
?IF(("ABC"+varvalue)="abc ",.t.,.f.)
= .T.
varvalue="C "
?IF(("AB"+varvalue)="abc",.t.,.f.)
= .T.

Notice that the varvalue will have unknown quantities in it (sources can be user input, external data etc), and in most cases I want an exact match, even if it has trailing spaces.

So in most cases I will use == as a definitive comparison (which only really applies to character values). If I want case insensitive, I'll put UPPER("aBc")=UPPER("abc"). If I want to trim 1 or both sides, I'll do that. It also makes it easier to find comparisons vs assignments when searching.

Also, I always use extra parenthesis around pairs of objects, to make sure Alpha's expression evaluator does not get confused about the order of operation (I've seen that on very rare occasions in some versions/patches of A5 that got it wrong), and also, Alpha evaluates expression from the right side, e.g.

logicvalue1 .or. logicvalue2 .and. logicvalue3

Alpha will evaluate it like this

logicvalue1 .or. (logicvalue2 .and. logicvalue3)

which is way different than what might have been intended, as in

(logicvalue1 .or. logicvalue2) .and. logicvalue3

With extra parenthesis, there is no question. In the interactive window

?.t. .or. .f. .and. .f.
= .T.
?.t. .or. .t. .and. .f.
= .T.

?(.t. .or. .f.) .and. .f.
= .F.
?(.t. .or. .t.) .and. .f.
= .F.

One more thing, is I will typically use .not.(value1==value2) as opposed to value1!=value2, as earlier versions of A5 did not support it, and my code is made to be fairly version independent, plus there were possibly bugs in the != operator in early versions of it I may have run into, so I stayed with the most reliable choice, although that may be overkill.