Eric Barro
ebarro at verizon.net
Tue Apr 29 12:13:02 CDT 2008
Trying to understand the scenario... 1. So...you have a recordset in SQL server that you pull into a VB.NET app to process the records whose main purpose is to parse field values and then updates the same records to make those values into meaningful records that you can hand over to another process, right? 2. The VB.Net approach is due to the fact that you can't achieve the same fluid results using just SQL server. Questions: 1. Do you actually display the data you grab for your datatable like in a grid? Or is it just a form with a button that triggers the underlying processes? 2. Do you grab x number of records, process them in VB.Net and then write the changes back to SQL server and then retrieve the next x number of records and so on? From: jwcolby <jwcolby at colbyconsulting.com> Date: 2008/04/29 Tue AM 10:43:45 CDT > Yes, that is correct. He is ending up loading the records into memory. > Then passing individual updates back for each row of data that he > changed. Yes, and most records have updates. > This method is not designed for doing large datasets like he is doing. > > It should be done on the SQL Server side. ROTFL. That is a definite NSS. Unfortunately I am not a DBA and with the responses I get from the SQL group I am not even going there. I can do this purely in VB.Net (it is cranking as we speak) so I will. > Just what are you updating...the UPDATE statement you would use to > do what you are doing. No idea. I thought I could find out from the DA after the command builder was finished building the update statement but I am getting an error if I try to access the update property. John W. Colby www.ColbyConsulting.com Robert L. Stewart wrote: > Yes, that is correct. He is ending up loading the records into memory. > Then passing individual updates back for each row of data that he > changed. > > This method is not designed for doing large datasets like he is doing. > > It should be done on the SQL Server side. > > > John, > > Just what are you updating...the UPDATE statement you would use to > do what you are doing. > > Robert > > At 09:40 AM 4/29/2008, you wrote: >> Date: Mon, 28 Apr 2008 17:44:24 -0700 >> From: "Eric Barro" <ebarro at verizon.net> >> Subject: Re: [dba-VB] vb.net - Updates >> To: "'Discussion concerning Visual Basic and related programming >> issues.'" <dba-vb at databaseadvisors.com> >> Message-ID: <0K02006A29SFSYJ0 at vms173005.mailsrvcs.net> >> Content-Type: text/plain; charset=us-ascii >> >> Yeah it is a terrible thing from a DBA point of view because it opens it up >> to SQL injection attacks since it builds your SQL statement on the fly. >> >> I've tried it before and since it is generating it on the fly it makes it >> all the more harder to debug and offers the least amount of control from a >> DBA point of view. So...I let SQL server do all the work on the back end >> when it comes to batch updates by collecting the parameters and sending it >> to SQL server to process for the records it needs to process. >> >> Based on what you are trying to do you are building an image of the data >> structure in memory, manipulating the data in memory and then committing the >> changes to the database in memory basically sending the update command for >> each record to the database back end right? Or am I mistaken in thinking >> that all of this magically happens by sending a single update command >> containing several individual update commands strung together?