BorlandTalk.com

qswami · Guest

Hello all,

We have a windows application developed using Delphi 5 + ADO and MS SQL Server 2000. In one of the parts of the application, we try to import data (if this info reqd. - this is basically an output of a another system and it is in CAM system format, typically a ODB format). The data is loaded in to a Tree component. (We use a third party Tree component here). When the same is saved to the data base it is compressed before saving using another third party tool, since the data saved can be quite as big as 7MB. When the user wants to view the data, the same steps are done in the reverse order, ie., get the data from the database, uncompress it using the same 3rd party tool used for compression, and load it to the tree component.
The datatype in the database is IMAGE.

Now, coming to the problem, when doing this process for several times randomly, the data saved to the database gets corrupted ie., it becomes of invalid format and cannot be
reloaded and used again. To resolve this intially we tried to remove all the third party component and dependencies, but the problem seems to persist. So, could it be due to some memory constraints of the system based on the following observations.
The number of page faults in the windows Task Manager shows a big number and
If the database is cleaned up by deleting many jobs it seems to work without any issues until at some point it starts showing up again regularly.

If it could be due to memory issues, any tips / ideas / suggestions to resolve this are most welcome.

Thanks,
qswami

Del Murray · Guest

What do you mean by the statement ...
" If the database is cleaned up by deleting many jobs it seems to work
without any issues until at some point it starts showing up again regularly"
Do you mean SQL server jobs that are scheduled ? if so , do you have some
that are running constantly ?

What happens to the data if you take the compressed data in the component
and save it to a memory var (of proper type cuz I dont know what the
component native format is) and then uncompress it back into the tree , then
back into the var, back to the tree, etc... do this over and over until you
have done it some order of magnitue that represents the number of times you
can shove it into the database before it fails. This should tell you if the
corruption is caused by the componenet or the database ..

Try taking a good var with compressed data and do a sql "insert" n times in
a row and see if the data is good. I have never seen sql server corrupt
data,... I would be very suspicious of the compress routine not freeing
memory or expecting you to free memory for it.

Next thing is ... how do you put it into the database ....
mytable.fieldbyname('somebigchunk').value := ?? or do you treat it as a
tblob or what ?

Do you have the latest MDAC ?

What patch level of SQL Server ?

Swami · Guest

Thanks for the reply.

Del Murray · Guest

If you save the data to the temporary ascii file, reload it to the tree and
repeat that cycle, many times does the data become corrupt?
I have seen reports before about creating streams and stringlists that even
if they were freed, they caused memory leaks. I have never experience that
but it could be what is going on. I avoid it (I think) by creating a string
object (or anyother) one time in the program startup, I then just reuse it
everywhere and allow it to exist until I close the program. You might try
the Nexus memory manager which has been recommended on this site and see if
that clears it up.
I store data in the db by using this construct

FileName := 'somefile';
(fieldbyname('docimg') as tBlobField).loadfromfile( FileName );