How can I delete a record with an @ID containing a @VM?

TIA

Rod

you can try

SELECT filename "some part of the id"

ED file name and then FD the one you dont want

or use the editor of your choice, since I dont know what

release or Arev you are using.

We have had this problem several times. What we have had to do is

a) Create a filename_NEW file. with one or two columns (fields) in the same location.

b) Copy the DICT.filename to DICT.filename_NEW (O)

c) write a routine that selects all the records(rows) in the file and then have it read each id and display the id and other critical data such as a name. and then let it give the operator the option to accept the record to be copied to the _NEW file. if the record is not accepted then it will just go on to the next record.

another option is to have the routine check for any @vm in the id, if none then write to the _NEW file.

d) when this is done rename the file to filename_old and the _new to filename in that order. Redo the indexing etc.

hope this helps.

Dale

We have tried to used edit or ed and it doesn't work. all that happens is that the record for the value prior to the @vm comes up and that is not acceptable.

Dale

If you know the key just delete it with a program.

Delete Rec from Handle, ID Then…..

If you don't know, then try a simple "PERFORM SELECT"

then on the READNEXT do

READNEXT ID,VMPART.

If there is something in VMPART, join the two fields

BADKEY=ID:@VM:VMPART

then delete that.

The Sprezzatura Group

[/i]World leaders in all things RevSoft[/i]

ok select & ed doesnt work

so

SELECT filename ….

SAVE.LIST …

EDIT the savelist keeping id with vm in it

GET.LIST…

DELETE filename

If there are just a few hundred records you could try

the way we do it under similar circumstances where we

may have a bad row to delete.

First backup the table!

Create a new table ensuring that the first 2 dict items

are the same as the original table.

Attach the new table.

Then use the COPYROW utility from the command window

to copy the acceptable rows across to the new table via

the manual method. You can take several rows across at

each copyrow.

Once you have all of the good rows in the new table

clear the old table and rebuild the indices on that table.

You may then bulk copy all rows from the new table back

to the old table.

Check the row count after to ensure that all good rows

have been copied.

Rebuild any indices on the old table.

Check the data is okay.

Delete the new table.

You are now okay to proceed.

Hope this helps.

Regards,

Kevin Gray

Graycorp

email [email protected]

View this thread on the forum...