T.R | Title | User | Personal Name | Date | Lines |
---|
311.1 | No | UTRTSC::BOSMAN | We're just sugar mice in the rain | Tue Mar 24 1992 12:06 | 6 |
| Hi,
According to a STAR's article: no. Maybe someone can reply if 3.0 is
supporting this (I thought it should be).
Sjaak.
|
311.2 | DATA_FILE | SHALOT::LAMPSON | Whatever ya do, ya gotta have FUN! | Tue Mar 24 1992 19:41 | 9 |
| The DATA_FILE function makes an excellent work-around, however.
You can do a DATA_FILE GET to get the record you want to copy.
Then do DATA_FILE PUT_FIELD for each field that that you want to
change. Then do a DATA_FILE PUT to write the new record. With
DATA_FILE, you can also check OA$STATUS to see if the GET and PUT
are successful.
_Mike
|
311.3 | How 'bout WRITE COPY? | UTRTSC::BOSMAN | We're just sugar mice in the rain | Wed Mar 25 1992 09:04 | 6 |
| Mike,
Ok, but can you WRITE COPY a record at once, providing the old and new
key?
Sjaak.
|
311.4 | The gory details | SCOTTC::MARSHALL | Pearl-white, but slightly shop-soiled | Wed Mar 25 1992 17:07 | 26 |
| Hi,
Re: WRITE COPY with segmented keys.
The way WRITE COPY works is rather weird. It opens the dataset for read, and
reads the required record. This is like the first part of a WRITE CHANGE
operation, so note that if you have a multi-field (ie segmented) key you need
to specify it with %KEY. This is because the code only allows one field for the
key; other fields are assumed to be the data you wish to change.
Once the record is read, the dataset is opened again for write access. The code
then craftily throws away the record buffer created for this second open, and
makes the write operation point at the read operation's record. Don't ask me
why it doesn't just do one open for 'update' in the first place...
The rest of the fields in the command are then written to the record, just like
WRITE CHANGE. The difference is, at the end a PUT operation is performed to
create a new record (the code assumes you've changed the key!), rather than
an UPDATE. Note for a segmented key, you may need to specify the new key using
%KEY rather than as individual fields. Also, I think the code may ignore new
values for other fields in some circumstances...
Sorry it's a bit vague, it's a while since I looked at the code, but it should
give you a few ideas...
Scott
|
311.5 | good in theory | ADO75A::BEESTON | | Thu Mar 26 1992 09:44 | 14 |
|
RE .2 But, I can also use the WRITE ADD function to get the same result
as the DATA_FILE functions and still have OA$STATUS supported
Are there any differences between the two results?
RE .4 Thanks for the info but I can't get it to work with any
combination of key field specifiers in the source and target
records. Using %KEY or the individual fields both return
OA$STATUS = 0 and the data file is not updated.
Thanks.. Liz
|
311.6 | the beauty(?!?) of ALL-IN-1: multiple answers | SHALOT::LAMPSON | Whatever ya do, ya gotta have FUN! | Thu Mar 26 1992 19:37 | 20 |
| >RE .2 But, I can also use the WRITE ADD function to get the same result
> as the DATA_FILE functions and still have OA$STATUS supported
The advantage of DATA_FILE over WRITE ADD is that with WRITE ADD
you must reenter each field. For the DATA_FILE method, ALL-IN-1
holds the current record in a buffer. You update the keys fields
in place in the buffer and then do a DATA_FILE PUT to create the
new record.
The WRITE function in V2.4 and before did not update OA$STATUS.
Maybe this has changed in V3.0?
The syntax for WRITE ADD (to effeciently get all the fields) would
be:
FOR DATA_SET WITH .%KEY == #KEYSYM DO -
WRITE ADD KEYFLD1=#NEWKEYFLD1, KEYFLD2=#NEWKEYFLD2, -
AFIELD1=.AFIELD1, AFIELD2=.AFIELD2, ...
_Mike
|
311.7 | How about DATA_FILE MOVE for copy? | TROA06::SUDARSHAN | | Sat Jun 13 1992 16:42 | 25 |
| Hi,
In light of the fact that 'WRITE COPY' does not seem to work for files
with segmented keys, which of the following operations is better in
terms of performance for copying records. I need to copy multiple
records at a time.
a. Using DATA_FILE GETs and DATA_FILE PUTs in a loop on a single open
dsab.
b. Open the same dsab twice (with different id's) and do a
DATA_FILE GET on the first and do a DATA_FILE MOVE and PUT to the
second.
I haven't tried either so far. Just a pre-emptive question. I have
another realted question.
If I operate using the first option (using a single open), where is the
record pointer after the PUT. Can I do a GET_NEXT to get the next
logical record from the previous GET or do I need to do a fresh GET?
Thanks in advance.
Sudarshan
|