|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Could someone answer a stupid dgv question?do something like: for each row... process data next in the "process data" routine I call a routine that goes through this whole scenerio for each row: Private Sub ProcessData dim connection string, dim connection object, open connection, build command object, update the qty field in another table from the current row insert row, close connection End Sub Stupid question: Is it necessary to go through all these steps for each row or should the "for each row..next" routine be between the open and close connection statements in the "process data" routine described above? Thanks, --Joyce P. Ah no. The ENTIRE operation should be done on the server in a stored
procedure. -- Show quote____________________________________ William (Bill) Vaughn Author, Mentor, Consultant Microsoft MVP INETA Speaker www.betav.com/blog/billva 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. __________________________________ "Joyce" <joyc***@noplace.com> wrote in message news:6n0p02ls7bbgh6rtvrongpnhkihbt7tg73@4ax.com... > Hi, when inserting rows from an unbound datagridview to a database I > do something like: > > for each row... > process data > next > > in the "process data" routine I call a routine that goes through this > whole scenerio for each row: > > Private Sub ProcessData > dim connection string, > dim connection object, > open connection, > build command object, > update the qty field in another table from the current row > insert row, > close connection > End Sub > > Stupid question: > Is it necessary to go through all these steps for each row or should > the "for each row..next" routine be between the open and close > connection statements in the "process data" routine described above? > > Thanks, > --Joyce P. Bill, the command object in the "process data" routine does use a
stored procedure but I still connect/close through each iteration. I'm trying to conceptualize doing the ENTIRE operation as a stored procedure as you suggest. Sounds like operation should do this: Client fills rows (eg order details) Client clicks "process" button Process button invokes stored procedure on server Stored procedure contains sql code to get the rows loop through the rows update qty in other table insert the row next row Is this more or less the correct scenario? Do you know of an exmple online? Thanks again, --Joyce On Mon, 6 Mar 2006 11:15:19 -0800, "William \(Bill\) Vaughn" <billvaRemoveT***@nwlink.com> wrote: Show quote >Ah no. The ENTIRE operation should be done on the server in a stored >procedure. > Hi, when inserting rows from an unbound datagridview to a database I > do something like: > > for each row... > process data > next > > in the "process data" routine I call a routine that goes through this > whole scenerio for each row: > > Private Sub ProcessData > dim connection string, > dim connection object, > open connection, > build command object, > update the qty field in another table from the current row > insert row, > close connection > End Sub > > Stupid question: > Is it necessary to go through all these steps for each row or should > the "for each row..next" routine be between the open and close > connection statements in the "process data" routine described above? > > Thanks, > --Joyce P. Well sort of. I'm not at all in favor of doing row munging that can (should)
be done on the server. Consider that an UPDATE statement can have very complex WHERE and SET clauses. It can use the JOIN engine to pull together data from several tables without having to create a cursor (which is what you're suggesting). I would dig into the TSQL UPDATE statement on Books Online (the SQL Server doc) which discusses these approaches in some detail. hth -- Show quote____________________________________ William (Bill) Vaughn Author, Mentor, Consultant Microsoft MVP INETA Speaker www.betav.com/blog/billva 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. __________________________________ "Joyce Perry" <Joyc***@noplace.net> wrote in message news:1m6p02luld00v9ah7qerh2r72uqs7b9ng3@4ax.com... > > Bill, the command object in the "process data" routine does use a > stored procedure but I still connect/close through each iteration. I'm > trying to conceptualize doing the ENTIRE operation as a stored > procedure as you suggest. > > Sounds like operation should do this: > > Client fills rows (eg order details) > Client clicks "process" button > Process button invokes stored procedure on server > Stored procedure contains sql code to > get the rows > loop through the rows > update qty in other table > insert the row > next row > > Is this more or less the correct scenario? > Do you know of an exmple online? > > Thanks again, > --Joyce > > On Mon, 6 Mar 2006 11:15:19 -0800, "William \(Bill\) Vaughn" > <billvaRemoveT***@nwlink.com> wrote: > >>Ah no. The ENTIRE operation should be done on the server in a stored >>procedure. > >> Hi, when inserting rows from an unbound datagridview to a database I >> do something like: >> >> for each row... >> process data >> next >> >> in the "process data" routine I call a routine that goes through this >> whole scenerio for each row: >> >> Private Sub ProcessData >> dim connection string, >> dim connection object, >> open connection, >> build command object, >> update the qty field in another table from the current row >> insert row, >> close connection >> End Sub >> >> Stupid question: >> Is it necessary to go through all these steps for each row or should >> the "for each row..next" routine be between the open and close >> connection statements in the "process data" routine described above? >> >> Thanks, >> --Joyce P. > Joyce,
You make me curious, if you want to use the your datagridview connected to a database, than why you use it not in combination with a bound datatable. They did a lot of work to make that easy for us. Cor Cor, the reason I have done things the way I have is that I need to
have something up and running, recording the line details and updating the quantity field in the Products table. I have been trying to do it the "easy" way since December. You and others here have been very helpful but tableadapters, bindindsources etc. are very strange when you first approach them. Slowly things are beginning to come clear to me but I can't learn if I can't even get started. Yesterday I managed to achieve my goal of inserting and updating. Now I can learn to do it the "easy" way. If you saw the Slashdot posts yesterday you will understand that I am not the only one who finds this convoluted and frustrating. Nevertheless, I am not giving up. Now that my app is working I can slow down and relax and paly with vb.net 2005. I just hope my efforts aren't wasted when Microsoft abandons vb due to lack of interest by the wider developer community. --Joyce P. On Tue, 7 Mar 2006 07:38:43 +0100, "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote: Show quote >Joyce, > >You make me curious, if you want to use the your datagridview connected to a >database, than why you use it not in combination with a bound datatable. >They did a lot of work to make that easy for us. > >Cor > Joyce,
Do you have a link for me, about this. > I am at TechEd in Amsterdam today, where I heard the opposite from what you > If you saw the Slashdot posts yesterday you will understand that I am > not the only one who finds this convoluted and frustrating. > wrote, so you make me curious. Can you reply your question please a little bit more again, than I will try to find an answer. Cor Cor, here's the link to the Slashdot posts:
http://books.slashdot.org/article.pl?sid=06/03/06/1435245 I just discovered this new message from you so I will restate question later. --Joyce On Wed, 8 Mar 2006 06:46:25 +0100, "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote: Show quote >Joyce, > >Do you have a link for me, about this. >> >> If you saw the Slashdot posts yesterday you will understand that I am >> not the only one who finds this convoluted and frustrating. >> >I am at TechEd in Amsterdam today, where I heard the opposite from what you >wrote, so you make me curious. > >Can you reply your question please a little bit more again, than I will try >to find an answer. > >Cor > Joyce,
That are just replies as some do on politicla blogs. However, it seems that C# people have forever to make it clear for themselves that they made the right choose and place everywhere this kind of messages. You see seldom done this spontaneously by vb.net developers. (You see it is wel done often by Linux users despite that 90% of the clientcomputers is Windows.). Cor Show quote "Joyce" <joyc***@noplace.com> schreef in bericht news:qn4u02d0j1nmju8hb2f77i70gpt2sj2750@4ax.com... > > Cor, here's the link to the Slashdot posts: > http://books.slashdot.org/article.pl?sid=06/03/06/1435245 > > I just discovered this new message from you so I will restate question > later. > > --Joyce > > On Wed, 8 Mar 2006 06:46:25 +0100, "Cor Ligthert [MVP]" > <notmyfirstn***@planet.nl> wrote: > >>Joyce, >> >>Do you have a link for me, about this. >>> >>> If you saw the Slashdot posts yesterday you will understand that I am >>> not the only one who finds this convoluted and frustrating. >>> >>I am at TechEd in Amsterdam today, where I heard the opposite from what >>you >>wrote, so you make me curious. >> >>Can you reply your question please a little bit more again, than I will >>try >>to find an answer. >> >>Cor >> > The only way the new datatable/binding sources/tableGizmos/etc/etc are
"easy" is if you use the wizards and don't need to add any logic/complexity beyobnd one table - otherwise it is a bottomless pit IMO. Unfortunately it appears VB was rewritten by folks that never used VB in the real world but read about it in books. They rewrote the databound stuff that was written about over and over (but never used in the real world) while they should have been creating ways to make "unbound" forms easier to write. We tried using the VB data stuff in a VB6 fat client conversion with about 200 forms/100+ tables and gave up in short order. We had to re-create the VB6 unbound form methods to get anywhere - and we really wanted bound forms to work. Turned out to be a waste of time. If it wasn't for the fact that VB6/ActiveX was getting hard to suport on the newer platforms we would have stayed with it. *** Sent via Developersdex http://www.developersdex.com ***  |
|||||||||||||||||||||||
Other interesting topics