I just had a d3/linux situation where an item id was 691*21 then char(140) then char(5)
then 89
and I did a select that showed just that item, but could only LIST it using that list;
when I tried to do DELETE INVC with that list active, it claimed 'item not found'

I was able to get rid of it by having a basic program
read in the pointer-file item into a variable, then open INVC to invc and DELETE invc,
list
so Basic saved my bacon here, but I'd enjoy knowing how to manage next time from TCL,
if anyone knows how. Oh, and doing CONTROL-CHARS with no option flag reports
the feature is 'on', that is control-chars are accepted on that system at this time.

I got the char() figures cited by exporting the select list to /tmp then doing od -c
/tmp/foo,
and octal 214 is decimal 140.

???

Question: Did you do something similar to:

LIST INVC WITH ID "691*21]"

or

SELECT INVC WITH ID "691*21]"
LIST INVC


Usually, the reason you can select an item but not find it is because it's
in the wrong group. It's found by scanning each group, but it is accessed
via a "random" read to a hashed group where the item is not.

Also usually, if you can SELECT fn and then LIST fn and see your results,
the DELETE should work. It means even though the id has strange characters,
it still hashes to the right place.

Too late now, but could you edit the bad item? If you use the Update
Processor, you can CTL+X+I and write the item to a new id deleting the old
item.

Was the file recently resized? If so, did the resize complete correctly?

Mark


"Frank Winans" <fwinans (AT) sbcglobal (DOT) net> wrote

"Mark Brown" wrote
then SAVE-LIST FHW then did an edit session on pf "fhw" to whack out all but
one line of the saved list. Then I did GL FHW and finally
COPY INVC
{I was wrong when I originally claimed I'd been attempting a DELETE at this step}
and got back 'item not found.'

Your guess about the resize is good, but no, I do not think so. However, this system
has a really ineffective battery-backed UPS and the city power goes out quite a lot...
I'm agitating for a fresh load of batteries or whatever it takes, but so far it's been a
long
string of GFE management sessions and file-save tape full restores. Given that, I don't
know what I was thinking presenting this as a stock d3/linux TCL question, and I value
the discussion points you've raised on the pathology of a semi-deranged rdbm box. I'll
be more observant and experimental if/when I have to revisit that box for something
similar, and report back if I see anything that may be of interest here.

On Mar 29, 8:28 pm, "Frank Winans" <fwin... (AT) sbcglobal (DOT) net> wrote:
Hi Frank

It seems that, somehow, you got over this problem - although I remain
a bit confused as to how you did so.

I don't understand why a Basic delete worked any better than any other
method. As Mark suggested, you should have been able to use a TCL
delete or a copy (d from an active list just as easily. They should
all end up looking in the same place. I can see that you would have to
use an active-list if there were unprintable (un-enterable) chars in
the id, but it shouldn't have made any difference what method you used
from there - they should all have performed the same hashing
algortithm and looked in the correct group.

If the problem was that the hashing algorithm somehow failed to
identify the correct group (issue!!!) then good ol' ED might have come
to the rescue, given its ability to progress though each and every
group with an ED INVC *. That could prove somewhat tedious if there
are more than a few items in the file though. One way to counter that
might be to find the line number in a full file select-list and
programatically EXECUTE an ED INVC * with a programatically prepared
number of edit-prestore EXescEXesc...s stacked on. Not elegant - but
should get you to the item so you can then FS it to another id and/or
FD it and then EXK.

Mike.

PS. We don't arf talk funny sometimes aye?

I have had similar problems.. In fact at one site, we have an item
we've been trying to delete for years.

If there is a demiliter, or certain other non printable characters in
the ID, the you can SELECT it, but when you ED it, the ID is split at
the control character. The editor, or DELETE or whatever you try at
TCL sees only half the ID and thinks you have new item.

It's hard to explain to a non pickie.

ITEM ID = "1234^ABCD"
SELECT FILE = "1234]"
one item selected
ED FILE
1234
EX
ABCD
EX

douglastatelman (AT) gmail (DOT) com wrote:
<snip>

If you're serious about "years", here's a different way to skin that
cat. Get everybody off of the system. Create a new file. Read through
the old file and copy every item from it into the new file *except* for
the item that you don't want. Archive the old file and change the name
of the new file.

And since you're going to read every item in the file, it might not be a
bad time to do some data cleanup/verification/summary_reporting/etc...

--
Allen Egerton aegerton (AT) pobox (DOT) com

On Apr 3, 3:36 pm, douglastatel... (AT) gmail (DOT) com wrote:
Curiouser and curiouser. What's the actual delimiter - an attribute
mark? If you can identify the group/frame you could dump (x it to find
out. Are there actually items with ids 1234, ABCD and 1234^ABCD in the
file - or does ED show new item for either or both? What happens if
you just ED * to get to the item without specifying the id or using an
active list - and what does the id show as then? If you save the list
created by the select statement above, how many lines/items are there
in it? How'd it happen? Is that too many questions?

Mike.

"allen-1" <allen-1 (AT) pobox (DOT) com> wrote
problem item turned up again. But this time my basic program cannot delete
it either, so I did just what you suggest;

<<get everyone off the system that might be using this file.
In d3/nt, they must actually log off of the d3 subsystem!!>>
RENAME-FILE INVC
to: INVC.FHW
CREATE-FILE INVC 1 32423
SELECT INVC.FHW
COPY INVC.FHW (I
to: (INVC
<<then I DX'd the INVC.FHW file>>
To be sure, you get a
'[202] myfooitem not on file'
complaint during the COPY,
but the rest of the items, the ones you want, get copied ok.
Oh, and also do COPY DICT INVC.FHW
to: (DICT INVC
In this example, there were no indexes to reproduce.
Speaking of housekeeping, the old file was sized at 37 frames
versus ISTAT INVC (RS suggested modulo 32,423
<not a typo, this is a monster file, like 230,000 items>

Now I can't help but wonder if the problem item came back as a result of the
really really bad file sizing, or if I should teach this client to use (F on all their
file
restores to prevent propagation of <items filed in improper group for that item id>...

On Apr 3, 5:18 pm, "Mike Preece" <mich... (AT) preece (DOT) net> wrote:
OK. Maybe that was too many. Here's just one, and it's a request more
than a question:

Can you identify the group the troublesome item resides in and copy
and paste the part of the dump (x output that shows the item header
info?

That should provide answers to most of my previous questions. For me,
its no longer about solving your particular problem - as you seem to
have done that already. Its more about understanding - and helping
others understand - what's going on.

Mike.

On Apr 3, 8:54 am, "Mike Preece" <mich... (AT) preece (DOT) net> wrote:
I don't think this is an issue of hashing or anything within the DB
table itself. The problem seems to be limited to the way that the TCL
DELETE command works, or more likely in the way that active select
lists store data.

It makes sense that the BASIC program would be able to delete the
item, becuase a BASIC program is capable of putting it in there in the
first place.

Active select lists are capable of having additional properties in
them, aside from just the item ID's. This is how exploded multivalue
information is stored (i.e. SELECT ... BY-EXP). It needs to keep track
of the associated value for each item in the active select list. I
suspect a delimiter is used to separate the item ID from the
associated multivalue position. It is likely that one of the "bad"
characters in your item ID is the delimiter used to separate the ID
from the MV position in the active select list. So, when the item is
pulled from the select list it is unwittingly truncated due to the
appearance of the delimiter. BASIC programs, however, don't keep track
of additional information that way, so the same restrictions would not
apply.

Luke Bucklin
Sierra Bravo Corporation
http://www.sierra-bravo.com