>>>< snip >
>>>I'm not too familiar with Foxpro, but I think that it's
>>>strings are limited to 255 bytes and that the DLL support in Foxpro is
>>>limited to C-style ASCII-Z strings anyway, which won't work with binary
>>>data. The string type supported by our DLL is the OLE BSTR type used by
>>>Visual Basic.
>>>< /snip>
>>>
>>
>>The STRING datatype in VFP can be 16M bytes in length assuming your system has the free memory (in theory, up to 2GB); it clearly is not ASCII-Z string types, since we can pass/retrieve data in strings that contains nulls, which would be seen as terminators in ASCIIZ strings. Since the problem appears to be with the integer and not the string fields being passed, I think it's a different problem.
>
>Well, i knew that his description of a VFP string was inaccurate, but i'm not familiar with 'OLE BSTR type' so I thought there might be a touch of truth in his answer.

You can always pass the address of a buffer in place of a string (use INTEGER rather than STRING @; use CLSHEAP to allocate a buffer of large size and pass the buffer to the DLL call by ref, receiving back the result, and then use the GetMem or GetMemString UDFs from CLSHEAP to copy out the contents of the buffer to a standard string.) Make sure to allocate a buffer of adequate size to hold the result. I use CLSHEAP buffers to copy BSTR data all the time, and in the vast majority of cases, a large string variable inited and passed by ref (prefix with @ in the call) and declared as STRING @ in the DECLARE...DLL would work just fine.