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

Problem with Image data type, serialization.

P: n/a
I have a field set to Image data type, and store a long string(possible other
objects)into it with size 5663, and returned with 5663+28 bytes.

These strings wil be deserialized after retrieving. However failde because
the bytes seems to include some extra bytes with \0 and 0x01 and have 28 more
bytes ahead of the original string.

How could I deal with it? Just remove the first 28 bytes? It this method
formal? I had thought the returned bytes should have the same size with the
one I stored into, it seems not, am I right?

Also, the select statement on a database with Image data type doesn't return
the actual data, but the 16 bit pointers. Any explanation for this?

Thanks.

Sep 27 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a

can you provide the code that converts your object (image, long string,
etc.) prior to the inserting into the db...can you post it?

I have experience with stuffing images, large txt fiels, large XML docs
into various SQL fields and don't remember coming accross this issue...
:confused:

Also, have you explored the Binary Field type (assuming we are talking
SQL), I tend to use an Image Field with just images, but for scenarios
when you don't know what your gonna hold...BLOB fields do the trick...
--
rviray
------------------------------------------------------------------------
rviray's Profile: http://www.msusenet.com/member.php?userid=4211
View this thread: http://www.msusenet.com/t-1871084574

Sep 28 '05 #2

P: n/a
Thanks for your reply.

The code is very simple, as follows:
===========================================
public byte[] GenerateXMLStringAndBuffer(string valueString)
{
byte[] theBytes=ConvertStringToBytes(valueString);
//string stringConverted=ConvertBytesToString(theBytes);//commented
return theBytes;
}

The problems is: When I call the above method, and stored the bytes(counts
5563 bytes) returned into a Image(BLOB) data field of database. When I
retrive the data back, I got (5563+28) bytes with 28 bytes at the beginning,
which contains invalid characters such as 0x01, \0, and lead to the
deserialization(ConvertBytesToString) to fail.
However, if I directly call the deserialization(ConvertBytesToString) just
after the serialization as shown in the above method. It returns the correct
string.
Therefore, the problem should be in the additional 28 bytes ahead of the
normal data cause the problem. I can manually resolve this problem, but I am
not sure whether this can be a formal way, that is, I would like to have some
theoratical support for the solution adpoted.

Any suggestions?
===========================================
public static byte[] ConvertStringToBytes(string StringToBeSerialized)
{
byte[] theBytes=System.Text.Encoding.ASCII.GetBytes(Strin gToBeSerialized);
return theBytes;
}

public static string ConvertBytesToString(byte[] theBuffer)
{
string tempString=System.Text.Encoding.ASCII.GetString(th eBuffer);
return tempString.Trim(new char[] { '\0'});
}
==========================================

"rviray" wrote:

can you provide the code that converts your object (image, long string,
etc.) prior to the inserting into the db...can you post it?

I have experience with stuffing images, large txt fiels, large XML docs
into various SQL fields and don't remember coming accross this issue...
:confused:

Also, have you explored the Binary Field type (assuming we are talking
SQL), I tend to use an Image Field with just images, but for scenarios
when you don't know what your gonna hold...BLOB fields do the trick...
--
rviray
------------------------------------------------------------------------
rviray's Profile: http://www.msusenet.com/member.php?userid=4211
View this thread: http://www.msusenet.com/t-1871084574

Sep 28 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.