I'm a total programming infant and need some help to administer a D3
Windows database. I'd like to take a particular field in 2000 records
(a get-list) in our customer file and delete the data in that
particular field. We don't have a test server so before I do something
irreversible I wonder if somebody could look at this program and
comment. There may be an easier was to do this but this is what I came
up with. I have compiled it so it least the syntax works. Thanks for
your help.

:ED MODS CM-FIELD-FIX
top
001 * DELETE DATA IN SINGLE FIELD IN CM
002 OPEN 'CUSTOMER*GC' TO CM ELSE STOP
003 EXECUTE 'GET-LIST J'
004 EOF=0
005 LOOP
006 READNEXT ID ELSE EOF = 1
007 UNTIL EOF DO
008 READ CM.REC FROM CM,ID THEN
009 CM.REC<49> = ''
010 WRITE CM.REC ON CM,ID
011 END
012 REPEAT

I'd change line 8 to be :

008 READU CM.REC FROM CM,ID THEN

Provided your "J" list is a list of the records you want to operate
on, should work fine

If you want to test, just make a copy of the file, change program
accordingly & give it a rip

Could avoid a program entirely with an editor prestore, but this
should work fine :-)

Good luck on your journey to mastery .... you would appear to be well
on your way, PROVIDED this field isn't cross referenced on indexed in
a related file :-)


On Jul 17, 10:39*pm, Joe Renaud <j... (AT) goadco (DOT) com> wrote:

On 2011-07-17 09:14:16 -0400, Ross Ferris <rossf (AT) stamina (DOT) com.au> said:

Agreed. Keep this simple rule in mind. If you intend to update a
record, ALWAYS lock it first.

The reason for the lock (READU) is to ensure you have exclusive access
to the record during the update.

Using READU, if another process already has the record locked, your
process will "pause" until it is released. If you wish to handle
situations where another process already has locked what you wish to
read, Check out the "LOCKED" clause, which is optional for the READU
statement.

In addition to the LOCKED clause, check out the RELEASE statement as well.


YES!. It always pays to run your tests against non-production data
first. As mentioned, create a test file. Better yet, for long-term
testing and development, restore your live/production account to a test
account. Just be careful of Q-Pointers within the test account that
may point to data in other live accounts.


I would remove this execute statement and do the GET-LIST externally.
The main reason is to prevent file updates as a result of accidental
execution of the program. Imagine at a later time, for whatever
reason, re-executing that program. You could unintentionally update
your file. Even worse, if the contents of the list "J" have changed,
you could update the wrong records.

Also, as a matter of best practices, you should give your saved lists
meaningful names.

Good luck with learning more about multivlaue databases. They have a
lot of power and are a lot of fun to work with.

--
Kevin Powick

On 17/07/2011 14:14, Ross Ferris wrote:
As long as the list doesn't include any records with fewer than 49
attributes...

--
Danny Colyer <http://www.redpedals.co.uk>
"I'm riding a unicycle with my pants down. This should be every boy's
dream." - Bartholomew J Simpson

"Ross Ferris" wrote
I really hate how much time we spend writing throw-away code.

Vendors could include a 'stuffit' utility for this sort of job,
or we could whip up an industry standard 'stuffit' and start
leaving it behind on each server we consult on...

It's not rocket science, and just a trivial coding exercise.

On Jul 18, 12:57*pm, "Frank Winans" <fwin... (AT) sbcglobal (DOT) net> wrote:
<--snip-->

<--end snip-->

Unidata has a MODIFY command that does this job nicely:

:MODIFY filename attribute operator value [record_IDs]
[selection_criteria]

Example:

:SELECT TEST.FILE WITH {whatever}
I don't know if any of the other flavors have a similar tool.

That's what PickWiki is for.

BTW, PickWiki has links to websites with utilities which have been
published by people over the years. Unfortunately those people
shutdown their websites, the links get broken, and we all lose the
benefit of their contributions. With "free" and "open" source code
comes a responsibility to ensure this kind of thing doesn't happen.

The net result is that ton of "stuffit" (or whatever) utilities have
been lost to the ages, even after they were published for the benefit
of all. (Lost, unless someone here can go contact some of those
authors and recover the code). That's the fault of the community.
Don't put it on the DBMS vendors. If you want to preserve such
libraries, well "It's not rocket science, and just a trivial coding
exercise."

T

"Frank Winans" wrote: