Prev: help with select
Next: Restoring German DB to US Server - Known Issues?
From: Erland Sommarskog on 8 Jun 2010 16:32
Iain Sharp (iains(a)pciltd.co.uk) writes:
> Okay, dumping the data to a file from the application and reloading it
> without the # character allows Crystal to display the image correctly.
> So, unless the application is doing something else to the data (and
> the manual says,
>
> /image?reads the raw data from FileName, assuming that this
> data is an image. An initial hash character (#) is added to
> the data before copying the data to Target. (The hash
> character is an indicator to show that image data follows.) No
> further conversion is performed on the data.
> /raw?behaves similarly to the /image switch, except that the
> data in FileName is assumed not to be an image; an initial
> hash character (#) is not added. No further conversion is
> performed on the data.
>
> Data stored /image is what I have, data stored /raw is working
> correctly. So I presume it's the substring() or right() that is
> corrupting it....

I would suggest that you look at the dump from the application in a binary
editor and compare with what you have in the database, not the least
after the stripping. One possility is that this small-endian thing causes
a byte swap.


--
Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

From: Iain Sharp on 15 Jun 2010 06:36
On Tue, 08 Jun 2010 22:32:43 +0200, Erland Sommarskog
<esquel(a)sommarskog.se> wrote:

>Iain Sharp (iains(a)pciltd.co.uk) writes:
>> Okay, dumping the data to a file from the application and reloading it
>> without the # character allows Crystal to display the image correctly.
>> So, unless the application is doing something else to the data (and
>> the manual says,
>>
>> /image?reads the raw data from FileName, assuming that this
>> data is an image. An initial hash character (#) is added to
>> the data before copying the data to Target. (The hash
>> character is an indicator to show that image data follows.) No
>> further conversion is performed on the data.
>> /raw?behaves similarly to the /image switch, except that the
>> data in FileName is assumed not to be an image; an initial
>> hash character (#) is not added. No further conversion is
>> performed on the data.
>>
>> Data stored /image is what I have, data stored /raw is working
>> correctly. So I presume it's the substring() or right() that is
>> corrupting it....
>
>I would suggest that you look at the dump from the application in a binary
>editor and compare with what you have in the database, not the least
>after the stripping. One possility is that this small-endian thing causes
>a byte swap.

Found it.

I'd forgotten that the app maintains database independance by chopping
blobs up into segments and storing segments 2+ in a different database
file.

I will now have to step up my plans to change the data types in the
application code to prevent it doing this...

So it's not a SQL problem at all.

Iain
First  |  Prev  | 
Pages: 1 2
Prev: help with select
Next: Restoring German DB to US Server - Known Issues?