BYTE Data Type

[tekytippy]

I use VFP 7 to access something called Sage Data Objects made by Sage the accounts company that links to their Line50 Software. It has a data type of BYTE which I cannot access, (I can write to but I cannot read from) each time I do I get an error:- Expression Could Not Be Evaluated.

Sage say they know this is because VFP does not support the BYTE data type.

How can I get round this?

 

[Mike Lewis]

tekytippy,

A byte is simply a single-character string; the value of the byte is the Ascii value of the string.

So, if the Sage function is returning a byte, its value would be:

ASC(MySageFunction())

If that doesn't make sense, could you post some more information: either the appropriate description from the Sage documentation, or the code that you have written which is not working.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[tekytippy]

Has anybody got any other idea's as Mike's ASC() does not work. It still seems that it cannot understand the BYTE value.

 

[tekytippy]

I am not sure if VFP can even read this type of data. Any suggestions if it cannot? Has anybody got any experience in getting data from other "seemingly incompatible" data sources?

 

[DSummZZZ]

What does it look like?
Between all of us in the forum, we have probably worked with every data type out there. But without seeing what data you are working with, it's sort of hard to determine how to work with it.
Like Mike said, a byte is basically a single character. So if you know what the value of that single character is on one end, there is most likely a way to interpret it on the other end.


-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[tekytippy]

It contains a numeric value i.e. 1, 2, 3 etc but I have to use the Sage Data Object (SDO) to get the data and this is where I think the problem is happening as it is the SDO that returns the "byte" data type. I just don't know how I can convert it before VFP comes up with the error.

I cannot write code to go straight to the code as I have to do it using the SDO.

Apparently Sage use something called RETREIVE, I think.

Does this help?

 

[rob444]

Just use a numerical variable to store the result from Sage.
ASC() only works with character values.
Thats why ASC() doesn't work.

Rob.

 

[DSummZZZ]

So after you get the 1, 2 or 3 back, you need to determine what it relates to on the Sage side. For instance, if the data in Sage is an actual 1, you're ready to go. Use VAL() or STR() if needed to convert to whatever data type you need. If the 1 in Sage s something else, we can go from there.


-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[tekytippy]

Dave

I will check more and get back to you on this. Thanks for the help so far though.

 

[wgcs]

Show us some of your code using "Sage Data Objects" so we can understand what you're doing. A Byte should be interchangeable with a single character, but it all depends on how that byte is referred to, because VFP may try to offer a VFP-style string instead of a single char, if you hand a function a character.....

 

[tekytippy]

This is the code I use to read the data from the TYPE field. This code fails on the first CASE statement with the error "Function argument, value, type or count is invalid"

z_transaction_value = objHeaderData.FIELDS['FOREIGN_GROSS'].VALUE - objHeaderData.FIELDS['FOREIGN_AMOUNT_PAID'].VALUE

DO CASE
CASE objHeaderData.FIELDS['TYPE'].VALUE = '1' && Sales Invoice
z_os_value = z_transaction_value
CASE objHeaderData.FIELDS['TYPE'].VALUE = 2 && Sales Credit
z_os_value = 0 - z_transaction_value
CASE objHeaderData.FIELDS['TYPE'].VALUE = 3 && Sales Receipt
z_os_value = 0 - z_transaction_value
CASE objHeaderData.FIELDS['TYPE'].VALUE = 4 && Sales Receipt On Account
z_os_value = 0 - z_transaction_value
CASE objHeaderData.FIELDS['TYPE'].VALUE = 5 && Sales Discount
z_os_value = 0 - z_transaction_value
OTHERWISE
MESSAGEBOX("A Customer Transaction Type: " + ALLTRIM(STR(objHeaderData.FIELDS['TYPE'].VALUE)) + " Not Known To OrderWise Has Been Encountered" + CHR(13) + "While Obtaining A Balance For Customer: " + ALLTRIM(this.z_account_number_to_post_to) + CHR(13) + "Please Report This To Technical Support",48,"STOP!&quot
ENDCASE

(Best to copy this into somewhere where you can view it better)

The offending line being
CASE objHeaderData.FIELDS['TYPE'].VALUE = '1'

I have tried the following:
CASE STR(objHeaderData.FIELDS['TYPE'].VALUE) = '1'
CASE VAL(objHeaderData.FIELDS['TYPE'].VALUE) = 1

Both return the same error message

I can write to the field however by using:

objHeaderData.FIELDS['type'].VALUE = 1

which suggests that even though the field is byte it accepts a numeric value.

Any more ideas? I would be most grateful as I am pulling my hair out!

 

[DSummZZZ]

But you're saying the other CASE statements work?
And also, is the actual value of objHeaderData.FIELDS['TYPE'].VALUE stored in SAGE equal to 1?
Suspend the program at the offending line and look at the data type there.
Maybe add a watch of nValue. If it stops, look at what type nValue is.

Try it this way:

STORE objHeaderData.FIELDS['TYPE'].VALUE TO nValue
DO CASE 
   CASE nValue = 1 && Sales Invoice
      z_os_value = z_transaction_value
   nValue = 2 && Sales Credit
      z_os_value = 0 - z_transaction_value
   CASE nValue = 3 && Sales Receipt
      z_os_value = 0 - z_transaction_value
   CASE nValue = 4 && Sales Receipt On Account
      z_os_value = 0 - z_transaction_value
   CASE nValue = 5 && Sales Discount
      z_os_value = 0 - z_transaction_value
   OTHERWISE
.
.
.

-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[wgcs]

I would recommend something similar, though slightly more deliberate:

loObj = objHeaderData.FIELDS['TYPE']
lnType = loObj.VALUE 
DO CASE
  CASE lnType = 1  && Sales Invoice
. . .

While BYTE is the same as a single character, the value one <> '1'..... the value one == CHR(1) (looks like a happy face in ASCII...)

the value 49 == '1'

 

[tekytippy]

Hi

This is the really confusing bit.

This line also causes the same error &quot;Function argument, value, type or count is invalid&quot;

lnType = loObj.VALUE



I also put this line above the other line

loObj = objHeaderData.FIELDS['TYPE']

In the debugger, I cannot on the loObj object either. It says it is an object but has no + at the side.

Any more ideas?

 

[wgcs]

for curiosity, find out what this shows:

WAIT WINDOW TYPE( &quot; loObj.VALUE &quot; )

 

[wgcs]

In the debugger, I cannot on the loObj object either. It says it is an object but has no + at the side.

FYI: This is normal. The VFP debugger doesn't show all the properties of COM objects... only the ones that have been already accessed in code (or the command prompt) since the object variable has been in the watch window. One likely reason for this is that simply querying a property of a COM object ALWAYS executes some code in the object, and may unintentionally change its state.

 

[tekytippy]

wgcs

&quot;for curiosity, find out what this shows:

WAIT WINDOW TYPE( &quot; loObj.VALUE &quot; )&quot;


The answer is U.

Is there any way we can convert it?

 

[tekytippy]

How do we deal with an undefined data type. Can we use it?

 

[KeithTrangmar]

The code you've posted so far looks distinctly like it may have been adapted from a VB example, is this the case? I wasn't aware that VFP could interpret the expression

objHeaderData.FIELDS['TYPE'].VALUE

because of the way the square brackets conflict with it's normal handling of strings? But if you're saying it definitely does, I'll not start an argument . My assumption, however, would be that the object's properties would be exposed by VFP in a manner that it's compiler is unlikely to stumble over. The above expression looks exactly like something that would be used in VB when extracting data from a particular field in an ADO recordset object, and the VFP equivalent of that should actually be as simple as

objHeaderData.type

where &quot;type&quot; is actually the field name. OTOH if you can actually get Dave S.'s suggestion of

STORE objHeaderData.FIELDS['TYPE'].VALUE TO nValue

to work, then a quick check of VARTYPE(nValue) will confirm whether nValue really is numeric or (possibly) a single character, in which case you should be able to check it's ASC() value instead.

HTH,

Keith

 

[Mike Lewis]

Keith,

I wasn't aware that VFP could interpret the expression
objHeaderData.FIELDS['TYPE'].VALUE

You're right of course that VFP can't handle the square brackets in that way, but COM objects can. It is not unusual in COM to &quot;subscript&quot; an array (more exactly, a collection) with a character variable.

Mike



Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com