>>>>Alan,
>>>>I think I found the reason. Initially I thought it was fault of VFPOLEDB but now I doubt. Looks like a .Net weirdness.
>>>>The byte array is passed as null when it's over 8000. Up to 8000 bytes you can pass multiple byte arrays to a procedure.
>>>>It works right with ADO even if over 8000 (OTOH it works right with ADO.Net when used with SQLOLEDB if I didn't overlook anything).
>>>>
>>>
>>>
>>>Hi Cetin,
>>>
>>>This is somewhat documented:
>>>DbType.Binary
>>>A variable-length stream of binary data ranging between 1 and 8,000 bytes.
>>>Note ADO.NET cannot correctly infer the type if the byte array is larger than 8,000 bytes. Explicitly specify the DbType when working with byte arrays larger than 8,000 bytes.
>>>
>>>Perhaps, OleDbType.LongVarBinary should be used.
>>>
>>>Thanks,
>>>Aleksey.
>>
>>Aleksey,
>>It's only documented for DbType.Binary (with a note for larger values as if it would work - oh noticed now that you pasted the note. OK tried that but didn't work).
>>However it doesn't work with other types like OleDbType.LongVarBinary (even under 8000 bytes). Internally OleDbType.LongVarBinary sets DbType to DbType.Binary (but then even 500 bytes fail with NULL). Only Binary is working with byte[].
>>I'm lost if it's .Net or VFP causing the error.
>>Cetin
>
>
>Hi Cetin,
>
>It looks like VFPOLEDB is at fault here, ADO.NET passes long data by reference and provider doesn’t handle them properly. We will consider fixing this issue in VFP9 SP2.
>
>Thanks,
>Aleksey.

Hi Aleksey,
Thanks for the info:)
Cetin