@listserver.u2ug.org
Subject: RE: [U2] Best practice for Sequential IDs using TRANSACTION
START COMMIT/RO...
From: Les Hewkin
What would you call a really big transaction?
A transaction should encompass all updates that should happen (or be
abandoned) as a group in order to insure logical data integrity
In my opinion...
NO : Retrofitting TRANSACTIONs into existing programs would be a
nightmare.
YES: Definitely use them when writing a new application from scratch and
even a new sub-system enhancement if it is pretty much self-contained
with limited, well-defined interfaces that write into the
That could have been simply overcome by locking the file instead of
individual records.
I have done very large transaction boundaries for a specific type of system
and they worked very well. Saves a lot of leg work and programming to
manually create a recovery process for a major batch updated.
From: Les Hewkin
What would you call a really big transaction?
A transaction should encompass all updates that should happen (or be
abandoned) as a group in order to insure logical data integrity at the
application layer.
Let me use an example, keeping the preceding statement in mind.
this helps
Les.
(only another 150 EMails to read)
-Original Message-
From: Stevenson, Charles [mailto:[EMAIL PROTECTED]
Sent: 16 June 2005 04:54
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Best practice for Sequential IDs using TRANSACTION
START COMMIT/RO...
Ah-HA! Some real
I came here for a flogging.
No you didn't.
Couldn't resist. Sorry.
Serious reply to follow.
--
Regards,
Clif
On Jun 16, 2005, at 12:31 PM, Bill Haskett wrote:
However, it's always possible I could use a good flogging. :-)
---
u2-users mailing list
u2-users@listserver.u2ug.org
To
Yes, that was the point. A record counter contains no information about
the record; it is an arbitrary pointer to the information. Our U2 (and
other MV) databases do not provide for a key that is, to use some SQL
implementation terms, AUTO_INCREMENT or INTEGER GENERATED AS IDENTITY.
So we fake
Fine by me, but get your own thread; this one's taken.
(Or at least add another sentence to the subject line.)
From: Clifton Oliver
...Control numbers, on the other hand, are a completely different
issue
Anyone want to discuss why most MultiValue systems don't know
the concept of
FYI. I took the liberty of forwarding this to the U2UG Enhancements
Committee.
--
Regards,
Clif
On Jun 15, 2005, at 10:01 PM, Steve Johnson wrote:
This would be a very worthwhile enhancement IMO.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Best practice for Sequential IDs using
TRANSACTION START COMMIT/RO...
Would this be a worthwhile enhancement request through U2UG?
Are Ken and I the only ones whining about this:
---
u2-users mailing list
u2-users@listserver.u2ug.org
Subject: Re: [U2] Best practice for Sequential IDs using
TRANSACTION START COMMIT/RO...
I just can't keep quiet any more.
Any auditor who depends on a non-information content,
sequentially assigned, record counters as an audit trail
ought to be flogged and sent back to Auditing
:[EMAIL PROTECTED] On Behalf Of
Clifton Oliver
Sent: Wednesday, June 15, 2005 10:49 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Best practice for Sequential IDs using
TRANSACTION START COMMIT/RO...
I just can't keep quiet any more.
Any auditor who depends on a non-information content
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Best practice for Sequential IDs using TRANSACTION
START
COMMIT/RO...
Charlie,
I don't see how that addresses the TRANSACTION problem.
If the call to your NEXT.AVAIL.ID routine happens after TRANSACTION
START, the id control item
If more people care, they whould weigh in.
Clif moved it into the U2UG Enhancement committee's queue.
I'm on that committee so I'll take it up there, but the more voices the
better.
-Original Message-
From: Bill Haskett
Charles:
No, you guys aren't the only ones. This is a
I'm reading through all these responses and probably won't respond to
each individually.
But I do thank you all for your input.
There are several suggestions like the one below that involve
incrementing the control record BEFORE the transaction starts. Either
grab a block, or grab a master
Missing sequential numbers isn't important to me, but it's a good point
for general discussion.
cds
From: Bruce Nichol
This is all well and good if the commit goes ahead, but if
rollback is the action, don't you lose a supposedly
sequential root key into the vapours?
Never to be seen
Ah-HA! Some real world transaction experience!
Just what I wanted, Les.
From: Les Hewkin
Start trasnactions
Readu control record then
record.ID = control record
write record
control record += 1
write control record
end
end transaction
This seems to work
Would this be a worthwhile enhancement request through U2UG?
Are Ken and I the only ones whining about this:
From: [EMAIL PROTECTED]
Ideally of course, the ID would be allocated by the DBMS
transparently when the record is inserted into the file, but
neither U2 product supports that concept
From: Brian Leach
...Windows service app) in Delphi... Mutex wrapper... thread safe.
... Socket API or SOAP API...
smart aleck.
Seriously, if you are going to use transactions I would guess
the only way to avoid maintaining the key for the duration of
the transaction (to go back to the
This would be a very worthwhile enhancement IMO.
SQL Server calls this an IDENTITY column, and, IIRC, it can be any column (aka
attribute), not only the primary key. That is also a useful feature when the
record key contains useful data but you still need to have sequentially assigned
numbers for
I just can't keep quiet any more.
Any auditor who depends on a non-information content, sequentially
assigned, record counters as an audit trail ought to be flogged and
sent back to Auditing For Dummies. If your auditor demands that, I'd
suspect they are a paper-based bean counter, not an
@listserver.u2ug.org
Subject: RE: [U2] Best practice for Sequential IDs using TRANSACTION
START COMMIT/RO...
Goo'day, Bob,
At 19:44 13/06/05 -0700, you wrote:
Come on, people. A request was made for options.
I guess I'm one of those to whom you are referring. Please accept my
abject apologies.
However
-Original Message-
Subject: RE: [U2] Best practice for Sequential IDs using
TRANSACTION START COMMIT/RO...
Come on, people. A request was made for options...
Okay so here goes:
Write a service application (e.g. Windows service app) in Delphi that
maintains a table of sequence
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian Leach
Sent: Tuesday, June 14, 2005 2:43 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Best practice for Sequential IDs using TRANSACTION
START COMMIT/RO...
-Original Message-
Subject: RE: [U2] Best
= [*1 or SUB.KEY = 0 if you set the dict record.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stevenson,
Charles
Sent: Sunday, June 12, 2005 1:26 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Best practice for Sequential IDs using TRANSACTION
START
But this would not keep those pesky auditors happy. In the following sequence,
how could they know that item 1*4 was missing?
1*1
1*2
1*3
2*1
etc.
Regards,
Steve Johnson
FXA Group Ltd
Bangkok
Original message from Bob Woodward on 6/14/2005 12:39 AM:
But his comments have generated a
Of Bruce Nichol
Sent: Monday, June 13, 2005 3:54 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Best practice for Sequential IDs using TRANSACTION
START
COMMIT/RO...
[snip]
This is all well and good if the commit goes ahead, but if
rollback is
the action, don't you lose a supposedly
To: U2UG
Subject: Re: [U2] Best practice for Sequential IDs using TRANSACTION
START
COMMIT/RO...
But this would not keep those pesky auditors happy. In the following
sequence,
how could they know that item 1*4 was missing?
1*1
1*2
1*3
2*1
etc.
Regards,
Steve Johnson
FXA Group
of a finger.
BobW
-Original Message-
From: [EMAIL PROTECTED] [mailto:owner-u2-
[EMAIL PROTECTED] On Behalf Of Steve Johnson
Sent: Monday, June 13, 2005 4:29 PM
To: U2UG
Subject: Re: [U2] Best practice for Sequential IDs using TRANSACTION
START
COMMIT/RO...
But this would not keep
Chuck,
The method I use may work for you, and not waste IDs (accountants hate
missing sequential numbers).
Call a NEXT.AVAIL.ID routine passing a GET code which
reads and locks the ID control item
pops an ID off the unused ID stack (explained below) or
picks up the next ID and
Charlie,
I don't see how that addresses the TRANSACTION problem.
If the call to your NEXT.AVAIL.ID routine happens after TRANSACTION
START, the id control item will not be updated nor will its lock be
released until TRANSACTION COMMIT (or rollback) is executed, even though
the NEXT.AVAIL.ID
31 matches
Mail list logo
