Bug with word_number_get() ?

[Mike Wilson]

I have run into an error migrating an application to v9 from v7. I narrowed it to this. It worked fine in v7. Can someone explain why this now is not working? What am I missing? Is this a bug?

dim vExAccML as C

vExAccML = <<%a%
Checking
Savings                 
Escrow                  
ATM                     
Cash                    
Chase Visa              
%a%
          

? word_number_get(vExAccML,"ATM",crlf())
= 0

[Keith Hubert]

Re: Bug with word_number_get() ?

Hi Mike,

What do you get if you type ?vExAccML in the Interactive? How do you test if vExAccML has captured string?

I just tried in V7, ? word_number_get(cstates(),"Maryland",crlf()) and got 20 as the result.

Did same again in V9, same result. No problem with this function.

[Tom Cone Jr]

Re: Bug with word_number_get() ?

Mike, I see the same problem with vers 9, but only if I create the list as you have done.

If I create the list like this, the function works fine. I think there's an issue with how the list is being created. Recommend you submit a formal bug report.

my_list = "One" + crlf() + "Two" + crlf() + "Three" + crlf()
?my_list
= One
Two
Three


?word_number_get(my_list,"Two",crlf())
= 2

Later...

Now I'm really confused.

The following script runs just fine in the interactive window and from a saved script on the code page.

'Date Created: 23-Jun-2008 03:02:06 PM
'Last Updated: 23-Jun-2008 03:05:00 PM
'Created By  : Tom
'Updated By  : Tom
dim my_list as C
my_list = <<%a%
Checking
Savings
ATM
Debit
Credit
%a%
'trace.writeln(my_list)
trace.writeln(ltrim(str(word_number_get(my_list,"ATM",crlf()))))
end

I can only imagine the difficulty with your script being that you've got non-printing characters in your string somewhere.

Perhaps others can clarify...

-- tom

[Lenny Forziati]

Re: Bug with word_number_get() ?

Mike, you have trailing spaces after each of your "words". Since you've specified crlf() as your word delimiter, it is trying to match these as well. Remove them and your example works properly.

-Lenny

[Mike Wilson]

Re: Bug with word_number_get() ?

Thanks Tom,

The issue arose because I am using table.external_record_content get() to generate the crlf() list that I amend prior to displaying in a list dialog, and I got the dreaded error:

"Data value cannot fit into a numeric field of size"

I narrowed it down to the word_number_get() not processing appropriately.

I will report it as a bug with this an other examples.

[Mike Wilson]

Re: Bug with word_number_get() ?

Lenny,
shouldn't matter. Always worked in v7.

' get accounts into list
	dim vExAccML as C
	vExAccML = table.external_record_content_get("accounts","acc_name","","Acc_type = \"Bank\"")

? vExAccML
= Checking                
Savings                 
Escrow                  
ATM                     
Cash                    
Chase Visa              

? occurs_words("savings",vExAccML) 
= 1

? word(vExAccML,3,crlf(),1)
= "Escrow                  "

? word_replace(vExAccML,"ATM","Banana")
= Checking                
Savings                 
Escrow                  
Banana
Cash                    
Chase Visa              
             
[B][COLOR="Red"]? word_number_get(vExAccML,"savings",crlf())
= 2[/COLOR][/B]

[Mike Wilson]

Re: Bug with word_number_get() ?

There must be something to it cause if I throw in a for-next sequence to alltrim() the crlf() list, it clears the issue:

dim vExAccML as C

vExAccML = <<%a%
Checking
Savings                 
Escrow                  
ATM                     
Cash                    
Chase Visa              
%a%

dim vAccL2 as C = ""
for each foo in vExAccML
	vAccL2 = vAccL2 + alltrim(foo.value) + crlf()
next

? vAccL2
= Checking
Savings
Escrow
ATM
Cash
Chase Visa

? word_number_get(vAccL2,"ATM",crlf())
= 4

[Tom Cone Jr]

Re: Bug with word_number_get() ?

Mike, Table.external_record_content_get() is supposed to retrieve the entire field value for each field in each record, including trailing blanks, right?

-- tom

[Mike Wilson]

Re: Bug with word_number_get() ?

Yes, tom
table.external_record_content_get() does include trailing blanks. The difference now is that in v8/9, the presence of those trailing blanks makes it so

"checking" <> "checking                       "

for the function word_number_get(), where in v7, the blanks didn't make a difference and it behaved more like our filters do, i.e. you can filter for "fieldname = \"value\"", without having to account for the presence of trailing blanks. Imagine if all our filters we had to account for trailing blanks? Whoa!

[csda1]

Re: Bug with word_number_get() ?

Mike,

Tom is correct that when fetching the records from a table this way, it is returning the whole field including trailing spaces. If it worked in version 7, I'd be very much surprised. If it does, then version 7 has the "bug", not version 8 or 9.

But since you can specify an expression in the function, use something like this

vExAccML = table.external_record_content_get("accounts","trim(acc_name)","","Acc_type = \"Bank\"")

[Mike Wilson]

Re: Bug with word_number_get() ?

Gee Ira,
Stop making it so simple! It did work in v7. I just have to find all those places with that code sequence and update them, I guess. Any code add-in utilities that you know of that might assist in finding all those sequences? :)

[Tom Cone Jr]

Re: Bug with word_number_get() ?

"fieldname = \"value\""

I never do it that way.

"trim(fieldname) = \"value\""

Is preferred unless the field width is only 5.

-- tom

[csda1]

Re: Bug with word_number_get() ?

Hi Mike,

Gee Ira,
Stop making it so simple! It did work in v7. I just have to find all those places with that code sequence and update them, I guess. Any code add-in utilities that you know of that might assist in finding all those sequences? :)

I just checked version 7. It returns the whole width of a field as I suspected. So I can't speak to why it was working in A5V7, but I suspect it was some other manipulation of the data that might have changed.

Calling something a bug is often done too quickly. One must understand what is happening, if there is a reason for it and what has changed between versions. There are many things that I don't like about the operation of a function or similar, but that in itself does not make it a bug. However, understanding what is happening and why is key.

[Mike Wilson]

Re: Bug with word_number_get() ?

Ira,

I just checked version 7. It returns the whole width of a field as I suspected.

I am not sure "It" in "It returns the whole field, as I suspected" relates to, but I'm guessing maybe you were confirming my response to Tom when I said

Yes, tom
table.external_record_content_get() does include trailing blanks.

So I can't speak to why it was working in A5V7, but I suspect it was some other manipulation of the data that might have changed.

I'm not sure what you might mean. It seems pretty simple to me. When the following code is run in v7 the function returns a value of 2, but in v8 or v9, the function returns a value of zero (0).

my_list = <<%a%
Checking
Savings                 
Escrow                  
%a%
? word_number_get(my_list,"Savings",crlf())

What 'other manipulation of the data' crosses your mind? It seems that the function in v8/9 now evaluates the trailing blanks when it used to not, kind of like it now uses == instead of =

dim v1 as C = "test1 "
dim v2 as C = "test1"
? v1 = v2
= .T.
? v1 == v2
= .F.

I agree with your comment regarding 'bug'. Hence the question mark in the title and the posting on the MB for evaluation before any reporting as such. And while 'bug' might not fit explicitly, the condition of a function changing behavior between versions, the reasons for it, and the effects from it, are certainly something I believe helpful to be documented and available to the 'public'. Documenting that a zero (0) as the value for the function parameter start_word (word_number) in the function *word_remove() will return the error " data value cannot fit into a numeric field of size ' I believe is certainly helpful. Having searched and gone through the documentation a bit researching this error, I didn't come across this as a source for this error, as most threads concluded that values within table fields and calculated field values were the culprit.

This thread has certainly taught me to trim when possible, even if not immediately required (with the current version). Thanks all.

[CALocklin]

Re: Bug with word_number_get() ?

Gee Ira,
Stop making it so simple! It did work in v7. I just have to find all those places with that code sequence and update them, I guess. Any code add-in utilities that you know of that might assist in finding all those sequences? :)

Mike, that's precisely what my Aims App Analyzer was designed to do. Personally, I don't know how others get by without something like that. I may not use it every day but I do use it multiple times a week. My updates/fixes are much more likely to be complete now than they were before I created it.