| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2929.1 | | UKVMS3::PJACKSON | Oracle UK Rdb Support | Wed Apr 02 1997 11:50 | 5 |
| He found V4.0 on a CD, installed it, upgraded the application to V4, and
then tried to upgrade to V6 again. It failed with error reading
metadata fllowed by rally-e-entpoierr, and conoupgrade.
Peter
|
| 2929.2 | Try V3.0A | 4GL::SULLIVAN | | Wed Apr 02 1997 18:18 | 11 |
| Peter,
Its been a long time since I heard about Rally
2.1 :-).
The first thing to do is try to get a hold of the
Rally 3.0 kit and upgrade to that. If that were
to work you should be OK, since that was our last
on-disk upgrade.
Mark
|
| 2929.3 | | UKVMS3::PJACKSON | Oracle UK Rdb Support | Thu Apr 03 1997 06:48 | 11 |
| I have a clearer picture of what the customer has done so far.
He has three systems. His live one which he has upgraded to V7 of Rally,
a remote one with Rally V2.3, and a test one he has tried v4 and V6.1
on. He had CDD 6.1, but the metadata is only on the live system.
I have suggested that he downgrade the live system to V4.0 and try to
upgrade the application to that version by doing a RALLY EDIT and A
RALLY UPDATE.
Peter
|
| 2929.4 | | UKVMS3::PJACKSON | Oracle UK Rdb Support | Fri Apr 04 1997 06:22 | 17 |
| The CDD had the wrong location for the database. Deleting it from CDD
and then integrating got rid of most of the errors. Only 4 remain. They
have downgraded their live system to 6.1 currently.
The remaining errors are 2*16612, 1*16147, 1*18166.
I suspect the 16612s may be caused by the other errors.
Note 506 seems to indicate that the 18166 is a new restriction (added in
V2.2) or that the old version could create something that caused the
error, though it should have been OK. In the later case recreating one
of the fields is the solution.
Note 2097 is pretty clear about the 16147 being a new restriction (added
in V2.3, eased in later versions), requiring a change to the
application.
Can someone confirm these impressions?
Peter
|
| 2929.5 | | UKVMS3::PJACKSON | Oracle UK Rdb Support | Fri Apr 04 1997 08:34 | 7 |
| They have another problem. The last day of this month is being displayed
as 043097. Before the upgrade it would have been 30-APR-1997. 300497
might be acceptable.
What could have caused this? How can it be corrected?
Peter
|
| 2929.6 | | M5::JOPPELT | New packaging. Same contents. | Fri Apr 04 1997 13:57 | 6 |
| re .4
Peter --
I would expect the same things that you did.
|
| 2929.7 | | M5::JOPPELT | New packaging. Same contents. | Fri Apr 04 1997 15:04 | 30 |
|
re .5
Haven't heard of CONVERT changing date formats on us.
Date formats are managed either at the form level (in/out formats
hooked to the individual fields) or at the GLOBAL level. (Under
MISCELLANEOUS, choose default formats.) Check if a format is
hooked to the field. If so, see what it is set to. If not, look
in GLOBAL and see what it is set to.
---
Bottom line, it seems that the application actually *DOES* convert,
but that there are some problems, integrity errors, etc., after the
convert is done. Is this correct?
And your assessment of the integrity errors in .4 seems correct to
me. I currently have ownership of your call to this customer, but
have been unable to reach him. I'm still trying.
BTW, initially I thought that there was a problem with the CONVERT
itself. I was going to suggest doing (under 2.1) a MERGE of the
application with an empty RGA and then seeing if that converts.
I've seen plenty of weird things get corrected by this trick.
Joe
|
| 2929.8 | | M5::JOPPELT | New packaging. Same contents. | Fri Apr 04 1997 19:51 | 23 |
|
Peter --
Got ahold of the customer. Worked with him for nearly 4 hours.
The ADL errors turned out to be the problem reported in topic 2836.
The other two integrity errors are legitimate, but they no longer use
this portion of the application, so will ignore them for now. At some
later date they will have to visit these two objects and determine what
the original designer intended. They may be able to eliminate one of
the fields, etc., or they will have to redesign something.
So their 4 integrity errors are satisfactorily addressed.
Still, they couldn't get the app to run. There is a startup ADL that
queries records from the database. Eventhough the records are there,
their DB-QUERY/DB_GET_FIRST fails with no-records-read. Turns out to
be a problem with RALLY mishandling the time-portion of date strings.
I reported the problem in topic 2932, and helped him work around it as
shown in that topic.
One happy Scotsman, he is! (And a pleasant fellow to work with!)
|