By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,521 Members | 1,447 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,521 IT Pros & Developers. It's quick & easy.

PHP, MS SQL, OBDC and variable length columns

P: n/a
So, the problem is that I query data out of a ntext (variable length
Unicode text) field, and it is corrupted near the end.

Yes, I know that the misfeatures odbc.defaultlrl and
odbc_longreadlen() exist, but what good are they if I don't know the
data size beforehand? No, setting it to a very high value is not
acceptable - it noticeably slows PHP down (as it is allocating the
large buffer) and still poses a limit which can be broken. No, I'm not
going to add an extra 'length' column to the tables just because PHP/
ODBC is being stupid, that's just a silly workaround.

Yes, I could datalength(column), but why should I have to write silly
workarounds and break my serialization scheme and database classes and
everything _and_ generate unnecessary queries on the database just to
get data out of it?

Yes, I've installed the latest MDAC. Yes, I could use extensions
providing native access to the database, but I _have_ to get ODBC
working as well. I read on some site that calling odbc_result()
multiple times on the cell will fill the buffer in chunks allowing one
to ultimately retrieve all the data, but it doesn't seem to work here.
Undocumented behaviour that got 'API improved' away?

It's a vicious circle, and yet from what I gather, PHP developers
considers this to be perfectly fine. If any PHP developers are reading
this - PHP's ODBC implementation along with its ill-bred hellspawn
odbc_longreadlen() blow so immensely they redefine the concept. It's
not a feature, it's a silly workaround for an issue that shouldn't
exist in the first place. There is absolutely no valid, sensible
reason why it works the way it works. If it's by design, then it has
been designed wrong.

Yes, some people are quite happy with odbc_longreadlen(), but maybe
they are willing to succumb to this idiocy and devise ugly hacks and
workarounds. If you have any suggestions for fighting this problem,
I'm more than willing to try anything out at this point. I've
exhausted my options, and this is quite effectively murdering me. I'm
pissed, it's cold and the wolves are after me.

Feb 14 '07 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.