You already are inside a transaction, why ask for another one? Let's go back to why you need transactions in the first place.
Doing an update that changes rows across the entire table and I mean a table with a half million rows to 2 million. This update is using a where clause that doesn't have an index available for use and you are doing a table scan on a general column. In SQL Server we just don't make indexes unless we really need them because the work of inserting into a lot of them acts like a bottleneck in insert statements. The use of the transaction sets up a shield around your table to protect your process from others as well as others from gaining information about something in process instead of completed and now factual. Are you using this to capture new PKeys generated and not continuing until it is correct? If so you might consider creating a stored procedure that receives the insert data as params and will return the proper pkey for the table via identity. So what are you doing within your transaction? On Tue, Mar 1, 2016 at 11:17 AM, Chris Davis <[email protected]> wrote: > Ok how about if I do this .. > > BEGIN TRANSACTION > > Stuff > > Then another BEGIN TRANSACTION > > -----Original Message----- > From: ProfoxTech [mailto:[email protected]] On Behalf Of > Stephen Russell > Sent: 01 March 2016 17:15 > To: [email protected] > Subject: Re: SQL Server Transactions > > Sorry you have to tell the server to keep them or chuck them. Then > disconnect because SQL is a disconnect API and nothing like a VFP cursor or > table. EVER. :) > > Create your connection. > > Pass the CRUD statement(s) > Commit or Rollback > > disconnect. > > > > > > On Tue, Mar 1, 2016 at 10:55 AM, Chris Davis <[email protected]> > wrote: > > > I think I may have found the issue, what happens if I > > > > BEGIN TRANSACTION > > > > Append records via VFP Remote View with Buffering at 5. > > > > And then if TABLEUPDATE is .T. > > > > So a SQL DISCONNECT and don't do a COMMIT? > > > > > > > > -----Original Message----- > > From: ProfoxTech [mailto:[email protected]] On Behalf Of > > Stephen Russell > > Sent: 01 March 2016 16:52 > > To: [email protected] > > Subject: Re: SQL Server Transactions > > > > Do these rows generate a PKey? If so do you need that for secondary > > table inserts as well? > > > > On Tue, Mar 1, 2016 at 10:50 AM, Chris Davis <[email protected]> > > wrote: > > > > > Thanks for this, but with READ COMMITTED being the SQL Server > > > default, in theory my appended records cannot be seen by other > > > clients until the COMMIT fires? > > > > > > -----Original Message----- > > > From: ProfoxTech [mailto:[email protected]] On Behalf Of > > > Dave Crozier > > > Sent: 01 March 2016 16:47 > > > To: [email protected] > > > Subject: RE: SQL Server Transactions > > > > > > Chris, > > > Sorry I may have clouded the issue, I just thought VFP tables and > > > not SQL Server DOH!!!.... it has been a long day! > > > > > > +1 for what Ted has said re Transaction Isolation Level. > > > > > > Dave > > > > > > -----Original Message----- > > > From: ProFox [mailto:[email protected]] On Behalf Of Dave > > > Crozier > > > Sent: 01 March 2016 16:40 > > > To: ProFox Email List <[email protected]> > > > Subject: RE: SQL Server Transactions > > > > > > Buffered records actually contain a -ve record number property which > > > exists until the tableupdate/tablerevert. > > > > > > See towards the bottom of that link. > > > > > > Dave > > > > > > > > > > > > > > > -----Original Message----- > > > From: ProFox [mailto:[email protected]] On Behalf Of Chris > > > Davis > > > Sent: 01 March 2016 16:25 > > > To: [email protected] > > > Subject: SQL Server Transactions > > > > > > Hi All > > > > > > If I start a SQL transaction and append records via a VFP View, > > > issue a table update but don't COMMIT the transaction are these > > > records available from another machine? If they are how could I > > > know that they have been appended in a transaction that may well end > > > up getting > > rolled back? > > > > > > Thanks > > > > > > Chris. > > > > > > Chris Davis > > > Acton Gate Systems Limited > > > > > > We are moving! Please note our new address from 1st Feb Hilton Hall > > > Business Centre Hilton Lane Essington West Midlands > > > WV11 2BQ > > > M: 07966 020473 > > > *: [email protected] > > > Web<mailto:[email protected]%0bWeb>: www.actongate.co.uk< > > > http://www.actongate.co.uk/> > > > > > > > > > ____________________________________________________________________ > > > __ This email has been scanned by the Symantec Email Security.cloud > > > service. > > > For more information please visit http://www.symanteccloud.com > > > ____________________________________________________________________ > > > __ > > > > > > --- StripMime Report -- processed MIME parts --- multipart/alternative > > > text/plain (text body -- kept) > > > text/html > > > --- > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cajidmylv8nv+jdtbkepzj-uhinp9hwibgcfnda_20_e4c+5...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
