CursorLocation, AppendChunk and a strange problem!

CursorLocation, AppendChunk and a strange problem!

Post by Mehdi Mousav » Tue, 09 Apr 2002 04:19:37



Hi folks,
I've developed a multi-threaded program that writes some data chunk by chunk
(32K) into an image data field of SQL Server 2000. The job of each thread is
to write some specific data taken from a specific hardware card and store
this data chunk by chunk into the image data fields. So each thread does
something as follows (pseudo code):

CoInitialize(...)
Open the connection
InsertANewRowInDatabase(...)
While(!done)
{
        Take the chunk from the hardware device driver
        AppendChunk(...)

Quote:}

UpdateTheRecordset()
Close the recordset, connection and whatever
CoUnInitialize(...)

This is done simultaneously under 30 threads! I've noticed a strange memory
usage in my program. I started to clarify what the heck goes wrong there, in
my program, and I finally noticed it was all because of AppendChunk() call.
Today, (fortunately), I found that if I change the CursorLocation from
adUseServer to adUseClient everything works fine - there'll be no memory
leak this way! Now, I'm trying to understand this completely and that's why
I asked about CursorLocation.

Any idea?
Cheers,
Mehdi
--
MSVC++ Programmer and a web developer
Wanna create your own ISAPI Extensions? Take a look at my favorite article:
http://www.codeproject.com/useritems/isapi_extensions.asp

 
 
 

1. Strange problem with appendchunk, stranger solution yet

I have a SQL table with an image field. The table is linked to an Access mdb
and I write to it using VBA code. We were writing new data to the image
field with the appendchunk VBA method. The data was PDF (acrobat files).
Worked fine for several months. Then had a requirement to put jpg files in
the same field. Tried using same code to appendchunk a byte array that now
contained the jpg file bytes instead of PDF files. It fails. We get an ODBC
driver error 3157. None of the conditions that would cause that error exist.
We do a test on another table with similar data structure. It works!
We realize that the only difference between the table in which we can import
and the other one that fails is that the one that fails has a primary key
constraint. We remove the primary key constraint and replace it with a
unique index and guess what. The inserts and updates to the table now work
ok.
Now problem is , previously we had immediate synchronization with another
table on another server working fine via replication. That  replicated table
had no PK constraint.  Now the replicated table does not get updated
anymore.

Now what the hey would a PKconstraint have to do with being able to update
another field or not using appendchunk when the only difference between what
works and what doesn't is the contents of the byte array being saved? The
jpg files were bigger than the PDF files but so what?

I just LOVE this sh......! <GGGGGGG> ;-)

--
Robert Dufour, MCP, MCT
President SGI IMS Inc.
www.sgiims.com

2. Making a CrossTab

3. CursorLocation Problem

4. return yes/no value if record found

5. Saving an image with AppendChunk problem

6. US-ALL-PS STAFF CONSULTANT

7. HELP!! SQL AND RECORDSETS

8. AppendChunk problems with SQL Server

9. DAO getchunk/appendchunk problems in Access 97 DB

10. AppendChunk Problem ???

11. Using AppendChunk problem