Thanks, Wirt for your input.
Here's the information on the set:
SET NAME:
NDC,AUTOMATIC
ITEMS:
NDC, X12 <<KEY ITEM>>
CAPACITY: 200003 ENTRIES: 170979
The values range from: "00002010102 " to "99999999999 "
Finds like these cause the behavior:
>Find NDC.NDC=00000000000
>Find NDC.NDC=00000000001
>Find NDC.NDC=00000000011
>Find NDC.NDC=00000000111
None of those values are in the dataset.
"Examine Paths" in Adager reports:
---------------------------------------------------------------------
I did not detect any synonym-chain errors in dataset NDC
---------------------------------------------------------------------
Undoubtedly, it's something to do with the BTREE's. As I said before, when BTREEMODE1 is off or the index is dropped for this master, the long wait just doesn't happen.
Weird stuff. And a side note: It's not that we're actually doing a find on that master in any application written to run directly on the 3000. It seems that the Minisoft ODBC driver is doing this find on the master for some reason when in the application it's a SELECT statement on a detail that uses this master. And as I said before, the FIND on the detail with the above values does not cause the behavior.
Original messages:
>
> No Serial read. It "freezes" for a while... several minutes. During this
> time, CTRL-Break works. But even in break mode the process shows up in
> Showq;active. If aborted, it still takes several minutes to abort.
>
> If it runs to completion, it does eventually return with "0 ENTRIES
> QUALIFIED".
Hello.
I have an interesting problem:
We have an Image Detail dataset with an X12 Search Item.
If we do a FIND in Query on the Automatic Master for that X12 with certain
Keys (that do NOT exist in the dataset), it takes several minutes to
complete. It should take milliseconds. Ok... That's wierd.
Now, that Automatic master has BTREE Indexing on it. If I turn off
BTREEMODE1 or remove the Index on that Automatic, the FINDs work just fine.
Also, Finds on the Detail using the same key work just fine with or without
BTREE indexing.
This seems to have been fixed in MPE 7.0 but in 6.0 and 6.5 it seems to be a
problem.
I looked through the Communicators for 7.0 and searched online docs
extensively but could not find anything mentioning the fix. Does anyone here
know where I could find information on precisely what the problem is?
Thanks,
Travis.
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
