The Storefront demo which shipped with Pervasive's Tango 2000 (not sure about it being with WiTango) included a TCF which included a counter procedure. This procedure used a counter table from the database which checked for the existance of the counter, created a new counter record if needed (great for launching new systems), checked to see if the record was locked (multiple times if needed), locked the record when it was free, grabbed the value, incremented the value, then unlocked the record. It can be called from any TAF file that has the TCF defined (i.e. local$crm in the case below) with the simple line:
<@ASSIGN local$NewID "<@CALLMETHOD local$crm 'GetNextID(name_of_counter)'>"> I'm not sure if things have improved or not but I stopped trusting the autoincrement function of MS SQL Server a few years ago. Dave Shelley had developed the Support Tracking system for EveryWare and we kept having problems with the increments becoming corrupt for various tables. We couldn't track down the source of the problem and I lost faith in it's ability to work properly. I think this was version 6.5 of MS SQL Server. Hope this helps, Steve Smith Skadt Information Solutions Office: (519) 624-4388 GTA: (416) 606-3885 Fax: (519) 624-3353 Cell: (416) 606-3885 Email: [EMAIL PROTECTED] Web: http://www.skadt.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lewis Sent: May 1, 2002 12:00 AM To: Multiple recipients of list witango-talk Subject: Re: Witango-Talk: Identity after Insert Perhaps getting out of the box and into a book may help.... I am going out on a limb but the only book published on Tango is: "Tango Web Application Construction Kit" by Ron Davis, SAMS His solution: manually account for the increment per record in each table insert and then search for that record Which gets to the heart of who REALLY provides the unique key for every record at insertion. I can't find it in the extremely short search of the book where he elucidates this point but I believe these are the facts, mam. {It may be a tcf} I believe he has a table that accounts for every table's next unique serial record value and increments that value but prevents anyone one else from incriminating the value until the increment is done. This stuff may be elegantly done with domain variables. Now if you use FileMaker Pro ... [as I do] It is very simple: [because you are already singularity connected to FileMaker Pro after the insert] ...a search action with the Search based on the previous insert result will yield whatever field you want. On 4/30/2002 at 9:29 PM -0400, this was written: >Brad, > >Sounds like you're using either MS-SQL or Sybase. Either way you don't have >to run a select after the insert. Both have a built-in variable for >auto-increment fields (@@identity) and you can either return it in your >stored procedure or from the next Tango action. > >The only problem with doing this in a Tango action is that there is no real >guarantee that you're seeing the correct identity field. For example, if you >are using two consecutive Tango actions, you could run into a situation where >two threads are doing an insert and the first one gets the identity field >only after the second insert - guess what you're getting for @@identity? >Yep... ;-) Remember, this has nothing to do with Tango - there is only one >identity variable and it will always be set ot the last identity field >inserted. > >Klaus > >On Tuesday 30 April 2002 08:37, Brad Robertson wrote: >> I am currently using a Direct DBMS action in wTango that calls a stored >> procedure to insert a record and then return the new identity of that >> field, it seems that works better than a insert then search action to get >> the identity field. I was wondering if 5.0 or later will have the ability >> to grab this field on insert, or if anybody has a less tedious way of doing >> this... >> > > Brad -- Tom Voice: 416 760 0268 Fax: 416 760 7263 E-mail: [EMAIL PROTECTED] Web Site: www.aboutcomputers.com ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
