What happens if you use different SETTING variables? Maybe setting DUMMY when
removing from B(1) interferes with the REMOVE from A. From your example it
appears to be REMOVE that's not working properly rather than SETREM.
- Original Message -
From: Womack, Adrian [EMAIL PROTECTED]
To:
A quick test on uv 10.0.8
And results was
A A
A A
A A
As expected.
Regards,
Stewart
-Original Message-
From: Ray Wurlod [mailto:[EMAIL PROTECTED]
Sent: Friday, 10 June 2005 15:42
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] [UV] SETREM REMOVE (bug in SETREM)
Changing the second DUMMY variable to DUMMY2 makes no difference.
I tried the same code in a PICK flavour account and it worked
properly! I checked VLIST on the SETREM statement and the code produced
in PICK flavour is different to that produced in PI/Open flavour!
So, maybe it's a PI/Open
We use them. they're good, though slower than i-type pseudo triggers, they
give more flexibility.
Triggers begin a transaction, which you aren't supposed to be able to step
through using a debugger.
Regards,
--
Stuart Boydell
[EMAIL PROTECTED] wrote on 10-06-2005 13.57.58:
I have found what I
I will be out of the office starting 10-06-2005 and will not return until
14-06-2005.
I will respond to your message when I return.
**
This email message and any files transmitted with it are confidential
and intended solely
I know that are good as they are very powerful. My point is I cannot
deploy them, if developers cannot debug programs which happen to contain
writes to files which have a trigger on them. I also know they start an
implicit transaction. This in itself does not mean that you cannot use a
debugger as
I like the sounds of this type of data security.
I'm still kind of new with VB.NET and UniObjects, but have a healthy concern
for security.
Could someone please answer this for me:
How can you pull data from a U2 file, via UniObjects, manipulate it in VB.NET,
and write it back to the file,
Just to add fuel to the fire - UniData triggers have no such
constraints. In fact, using the debugger was how I discovered that our
(old) development team thought it would be a good idea to install
triggers on a large client site at the end of the day. The next morning
wasn't a good day in support
Hi Dave
Could someone please answer this for me:
How can you pull data from a U2 file, via UniObjects, manipulate it in
VB.NET, and write it back to the file, via UniObjects, via stored
procedures, and without directly accessing the files from UniObjects? I'm
just looking for basic general
This is your opportunity to get answers to some of those burning
questions you have.
I will be in the Greater Kansas City area the week of July 18th and
have three complimentary four-hour on site consulting visits still
available. This visit consists of two presentations of your choice from
No, you can't get past the write statement if you are running a program
in RAID. If you hit a DEBUG statement then execute a GO, you're still
not going to be able to get past the WRITE statement to a triggered
file. At least that's been my experience not too long ago on UV 10.1.
BobW
Don't you folks think this is a bit of yelling The sky is falling!? I
mean, who's going to produce a system that doesn't have audit trails,
account verifications, or some other way of protecting against such
illegal operations. Locks only keep honest people honest, and the same
can be said of
Don't you folks think this is a bit of yelling The sky is falling!? I
mean, who's going to produce a system that doesn't have audit trails,
account verifications, or some other way of protecting against such
illegal operations. Locks only keep honest people honest, and the same
can be said of
Hi,
I will be out of the office from June 13th through June 15th. I will
return on June 16. I will not have access to e-mail or voice mail. If
a you need an immediate response to your e-mail please e-mail
[EMAIL PROTECTED] or you can call Frank at extension 467.
Thanks and have a great day!
No DEBUG statement is involved, although the equivalent I guess in
either a control-C followed by entering D or RAID from the command line.
This is very frustrating as I know how powerful triggers can be, and I
want to deploy them widely, but I cannot do this while this design BUG
is there.
For files with sequential numbers as record IDs, it is common practice
to use a control item (in dictionary or in a special control table) to
get the next sequential id counter, then write back the incremented
counter ASAP so it is available for the next process that needs to do
the same. Some
On Fri, Jun 10, 2005 at 10:57:53AM +1000, David Jordan wrote:
Could you explain a little more fully how you do this?
Thanks
Will Johnson
Within UniVerse Basic is an AUTHORIZE Statement which allows you to give the
program different access rights to the user running the program. Ie
One approach is to determine in advance how many keys you'll need then generate
and store these in a text file. As you work through the main loop, read them
from the text file and write the successfully-used ones into another text file.
(Sequential file I/O is not counted as part of the
Don't you folks think this is a bit of yelling The sky is falling!? I2
reasons.
1. SOX and a number of international regulations have criminal liabilities
for senior executives and directors to ensure that they prevent issues.
2. A major reason why big organisations are replacing U2 systems is
One thing I would add to this is to always check to see if the key exists on
the file that you are writing to before stepping on an existing record.
Depending on how long your records live and how many characters you choose
for your sequential key, you can theroetically have dups. We do exactly
I feel like Winnie-the-Pooh here, Ray. I'm not following you.
Are you saying reserve a block of N IDs before starting the
transaction, by incrementing by N the traditional next-seq-id control
record thereby freeing the ctrl item for use by other processes?
What's the point of the 2 sequential
One thing I would add to this is to always check to see
if the key exists on the file that you are writing to
before stepping on an existing record.
I'm not concerned about fleshing out my little READVU SEQ.ID . . .
WRITEV SEQ.ID+1 . . .
Yes, you have to check for existing records and worry
How about replacing:
Some variation on this theme (probably involving a utility
subroutine):
READVU SEQ.ID FROM ctrl.fvar, ctrl.id, n ...
WRITEV SEQ.ID+1 TO ctrl.fvar, ctrl.id, n
WRITE NEW.REC TO fvar, SEQ.ID
with some variation of:
OPENSEQ path TO ctrl.fseq ELSE ...
READSEQ
23 matches
Mail list logo
