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.
ECTED] On Behalf Of Stevenson, Charles
> Sent: Thursday, June 23, 2005 10:37 AM
> To: u2-users@listserver.u2ug.org
> Subject: RE: [U2] Best practice for Sequential IDs using TRANSACTION
START
> & COMMIT/RO...
>
> In my opinion...
>
> NO : Retrofitting TRANSACTIONs into exi
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 par
users@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 da
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. (Plea
Hope 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!
ll, need I say more. :-)
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Clifton Oliver
> Sent: Thursday, June 16, 2005 11:55 PM
> To: u2-users@listserver.u2ug.org
> Subject: Re: [U2] Best practice for Sequential IDs usin
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 ch
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
"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
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
unday, June 12, 2005 4:26 PM
> 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.AVA
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[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 ke
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,
> seque
> Sent: Wednesday, June 15, 2005 8:53 PM
> 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 o
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 http:
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 Info
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
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 t
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 concep
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
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 b
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 numbe
-
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:
> -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
m
04
To: u2-users@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 accep
ster
wants options, so lend a hand instead 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
Steve Johnson wrote:
>> 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.
It strikes me that any system which relies on allocating a
sequential key at the start of an update runs
nt: 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 those pesky auditors happy. In the following
> sequence,
> how could they know that item 1*4 was mis
AIL PROTECTED] On Behalf 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&quo
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 modificati
Goo'day,
At 10:39 13/06/05 -0700, you wrote:
But his comments have generated a modification idea to my earlier
suggestion. If, before the TRANSACTION START command, you get a "next
available ID" then use that as a "root" value, you can then create a
sequential number with an internal sequentia
vailable.
As a side comment, this method will also make it easy to keep records in
a sorted, associated order. You could even get a count of process runs
by selecting @ID = "[*1" or SUB.KEY = "0" if you set the dict record.
-Original Message-----
From: [EMAIL PROTECTED]
[ma
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 routin
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 incre
35 matches
Mail list logo
