Calculating ETA for data transfer.

  • Thread starter Thread starter decrypted
  • Start date Start date
D

decrypted

I asked this a few months back, and once in February...still havn't come up
with a decent way to do this using the System.net or sockets namespaces (or
ado.net for that matter)...

You have 2 files. one is 10K and one is 100MB and your tansfering these
files into SqlServer 2000 in a Windows Forms based application using
ADO.NET. You would like to show the progress of the file transfer via a
progress bar (or even just track the progress internally to make things
simple). How do you accomplish this without writing a remoting wrapper?

I have explored a number of options from calculating ETA based on beta
results from threaed packet transfers over the network while taking into
consideration sql server processing times, but it has failed. I did write a
remoting framework that basicaly transfers the DS chunk by chunk and updates
client of its current chunck in series, but this is totally inefficient. I
think I've looked at everything ADO.NET and Sql Server 2000 have to offer
without any success.

Any ideas or thoughts are welcome...If I do come up with a sollution I will
be sure to write a public article on it (unless someone beat me to it of
course).

Regards,
dec
 
We've talked about this before. First, ADO (or ADO.NET) is not (yet) a good
bulk copy utility. If all you're doing is moving data (especially data this
size) you should use DTS. ADO.NET 2.0 includes BCP which can do the same
thing. You can call BCP today using SQL-DMO.


--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
If you remember our discussion, BCP was out of the question, and I don't
care to go over the many reasons why. ADO.NET is more than sufficient for
data transfer when inserting files as blobs into SQL Server for 99% of
documents. In my applications context, users are merely uplaoding files to
sql server where the avg file size is 1MG. The documents are attached using
thier own background thread, so performance really doesn't matter...were not
talking about a mission critical function here. The point here is not to
track how long it take for a blob to be inserted into the server once the
data is already accross the wire, the point is to show the status of the
data transmission over the wire....it takes alot longer for clients
connecting to New York from Hawaii to get the blob across the wire than it
will to stick it in the DB.

Hope that clears things up,
dec
 
Back
Top