Text fields when connecting .NET and 4D Server via 4D ODBC Driver
Did anyone already connected a .Net app to 4D Server using 4D ODBC
Driver via ODBCConnection? I'm having trouble with Text Fields. I only
get about the first 200 characters from them. I already tried to use
DataReader.getBytes() instead of getString(), but the problem remains.
Another problem is that I get the "128 and over" ascii characters
correct from Alpha Fields, but from Text ones they come unreadable -
seems like the ODBCConnection from .NET framework converts the contents
of Alpha Fields to the selected Windows character set, but not Text
I'm considering also to use 4D procedures to get the text I need, doing
the character set conversion on the server side, but I didn't find how
to execute a procedure using 4D ODBC Driver, neither know if it's
It's important to say that using win32 applications there's no such
problems. It's still an alternative to use win32 for the task, but only
if .NET conectivity via ODBCConnection with 4D prove itself impossible.
Our environment is 4D Server 6.5 using 4D ODBC Driver 2004.4. I've seen
that, prior to 2004.4, ODBC Driver failed when acessing an Alpha Field
of size 80 when it's totally filled, so, altough the server and the
driver aren't from the same version, it's the best match we found so
Re: Text fields when connecting .NET and 4D Server via 4D ODBC Driver
> I'm having trouble with Text Fields. I only
> get about the first 200 characters from them.
What type are you specifying on the .NET side when you bind?
According to the 4D ODBC Driver documentation the 4D Text type should be
mapped to "SQL_LONGVARCHAR" whereas Alpha is mapped to "SQL_VARCHAR".
Also, your call to SQLFetch (or whatever the .NET equivalent is)
*should* return a SQL state of "01004" or "String data, right truncated"
to let you know that the data was truncated. Also the return value
should be "SQL_SUCCESS_WITH_INFO". Is this not occurring?
If it is, try passing the statement handle to SQLGetDiagRec (or, again,
the .NET equivalent) and see what the "error" message has to say (there
should be at least one).
Finally, IIRC, ODBC with .NET is really done via ADO, with an ODBC ".NET
data provider" in the middle. The problem may be at the ADO/ODBC layer,
not the ODBC/4D layer (also indicated by the fact that you can get Win32
apps to work). My point being you might be able to research similar
issues down that path rather than looking at the ODBC/4D layer.