| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2409.1 | Known problem | SCARY::CHARLAND | ORACLE CODASYL DBMS Engineering | Thu Aug 24 1995 14:15 | 9 |
| 2409.2 | That was quick! Thanks!!! | ORAREP::CSC32::J_HANLON | | Thu Aug 24 1995 14:21 | 8 |
| 2409.3 | Need Workaround | M5::DMACKENZ | | Tue Mar 04 1997 12:39 | 13 |
| I have a customer with this same problem on DBMS 5.1A. He cannot
upgrade and needs a workaround. He has already tried specifying
different time values to get the dates he wants, but no workaround
has been found yet. The problem occurs both when he queries using
a calc set and this date key and when searching the realm.
I'm hoping that some insight into the problem with the conversion
will lead to a workaround.
Thanks,
Diane
|
| 2409.4 | Found it | M5::DMACKENZ | | Wed Mar 05 1997 11:50 | 13 |
| FYI,
I figured it out. If the first four bytes in the date's quadword for
the record is the same as the first four bytes in the low-end comparision
date's quadword, DBMS is considering it a match. This makes the cutoff
for the problem down to the fraction of a second.
This helped to determine the scope of the problem. For my customer, it
was just a few minutes. Now he can determine if it's worth adding
extra code in his application to check the retrieved record's date and
ignore it if it was an erroneous retrieval.
Diane
|
| 2409.5 | | ORAREP::AUSS::GARSON | DECcharity Program Office | Wed Mar 05 1997 16:34 | 5 |
| re .4
One longword of clunks is a shade over 7 minutes. Hence code that does
ADT comparisons by comparing only the high longword can consider times up
to this much apart as equal. I am not sure whether this is relevant but...
|