List:MySQL ODBC« Previous MessageNext Message »
From:Peter Carter Date:March 22 2002 1:11am
Subject:Re: Has anyone had any trouble
View as plain text  
Small chunks are relitive. Your problem is not what you probably think. The 
transfer is actually in the hands of the ODBC Manager (IE: ADO). Think TEMP 
FILES and WEAK TCP/IP Stack. ODBC specs suggest a packet size no larger that 
1400 bytes anyway. Anything else is unsupported and optional.

1) check the drive space of your C drive.
2) Consider more memory
3) If 1 and 2 are not the case, I bet you are running 95/98/me with a fixed 
resource stack. In which case you are stuck.
4) Consider going NATIVE client. It works as advertised.

That aside,consider what large blocks and / or chunks do to the SERVER. It 
takes atleast 3 times more internal resources (based on time,diskusage,and 
memory) to deal with large amounts of data. That is, your effective upload may 
take longer but the usability to others DURING this process is still ok. Small 
chunks have proven the test of time, even before RDBM's could even deal with 
ray data that size. In short, large bulky data streams are not scaleable.

Quoting "Devore, Jacob" <JDevore@stripped>:

> send large blobs across the network with odbc?  Every we are starting to
> put
> larger data chunks into the database and are have problems.  I am send data
> and if the chunk is over 1/2 a mb the driver returns an error that the
> connection was lost.  We have plenty of memory local and on the server.  I
> wrote it to throw the whole chunk up there since we are all on buff
> machines
> and need the speed.  Can anyone think of a way to solve this problem
> without
> have to send small chunks?
> Thanks,
> jake
> ---------------------------------------------------------------------
> Please check "" before
> posting. To request this thread, e-mail myodbc-thread5204@stripped
> To unsubscribe, send a message to the address shown in the
> List-Unsubscribe header of this message. If you cannot see it,
> e-mail myodbc-unsubscribe@stripped instead.

Has anyone had any troubleJacob Devore22 Mar
  • RE: Has anyone had any troubleArmin Schöffmann22 Mar
  • Re: Has anyone had any troublePeter Carter22 Mar
  • Re: Has anyone had any troublePeter22 Mar