Prev: DB Editor
Next: rtf to HTML
From: Geoff Schaller on 6 Dec 2009 06:39 Using VO2Ado. I am saving binary data perfectly into a SQL table but when I read it back it is being corrupted. For example: uValue := oServer:Fieldget(BINDATA) // this correctly gives me an object of type AdoLongBinary cValue := uValue:Value The cValue is "almost" correct but there are some characters which are inverted or changed. Does anyone know what I am talking about here? Regards, Geoff Schaller
From: Johan Nel on 6 Dec 2009 06:55 Hi Geoff, Geoff Schaller wrote: > I am saving binary data perfectly into a SQL table but when I read it > back it is being corrupted. For example: > > uValue := oServer:Fieldget(BINDATA) > > // this correctly gives me an object of type AdoLongBinary > > cValue := uValue:Value > > The cValue is "almost" correct but there are some characters which are > inverted or changed. > Does anyone know what I am talking about here? Sounds to me like a character that is incorrectly treated as an Escaped character. Had similar troubles in Postgres with the "\" character, which was rectified by "\\" it when saved. PG also has a quote_literal(bindata) function to treat this correctly. I don't believe it happens when you retrieving the data, it happens when you upload it into the database. Will have to find the matching SQL-DB setup/function to treat Escaped characters literally. HTH, Johan Nel Pretoria, South Africa.
From: Johan Nel on 6 Dec 2009 07:12 Sorry some misconception there, although the priciple stays the same. quote_literal is used to define the data contains ' characters. From the manual: standard_conforming_strings (boolean) This controls whether ordinary string literals ('...') treat backslashes literally, as specified in the SQL standard. The default is currently off, causing PostgreSQL to have its historical behavior of treating backslashes as escape characters. Johan. > > Sounds to me like a character that is incorrectly treated as an Escaped > character. Had similar troubles in Postgres with the "\" character, > which was rectified by "\\" it when saved. PG also has a > quote_literal(bindata) function to treat this correctly. > > I don't believe it happens when you retrieving the data, it happens when > you upload it into the database. Will have to find the matching SQL-DB > setup/function to treat Escaped characters literally. > > HTH, > > Johan Nel > Pretoria, South Africa.
From: Ginny Caughey on 6 Dec 2009 08:21 Hi Geoff, What is the data type of the SQL column? If you retrieve it using .NET instead of VO, do you get the result you expect? -- Ginny Caughey www.wasteworks.com "Geoff Schaller" <geoffx(a)softxwareobjectives.com.au> wrote in message news:IJMSm.60622$ze1.12861(a)news-server.bigpond.net.au... > Using VO2Ado. > > I am saving binary data perfectly into a SQL table but when I read it back > it is being corrupted. For example: > > uValue := oServer:Fieldget(BINDATA) > > // this correctly gives me an object of type AdoLongBinary > > cValue := uValue:Value > > The cValue is "almost" correct but there are some characters which are > inverted or changed. > Does anyone know what I am talking about here? > > Regards, > > Geoff Schaller >
From: Geoff Schaller on 6 Dec 2009 19:25
I've found the bug - it is in MemoWrit() Try this: cValue := MemoRead("C:\temp\g1.jpg") MemoWrit("c:\temp\g2.jpg", cValue) Substitute in any jpg name you wish and whilst MemoRead correctly reads binary data into a string, that data is not correctly written back out. It's something to do with ANSI to OEM conversion. Cheers, Geoff "Geoff Schaller" <geoffx(a)softxwareobjectives.com.au> wrote in message news:IJMSm.60622$ze1.12861(a)news-server.bigpond.net.au: > Using VO2Ado. > > I am saving binary data perfectly into a SQL table but when I read it > back it is being corrupted. For example: > > uValue := oServer:Fieldget(BINDATA) > > // this correctly gives me an object of type AdoLongBinary > > cValue := uValue:Value > > The cValue is "almost" correct but there are some characters which are > inverted or changed. > Does anyone know what I am talking about here? > > Regards, > > Geoff Schaller |