Ok, here is the story.
You can attach a TurboIMAGE database to many Allbase DBEs. The TurboIMAGE
fileset will contain a single TC file with one record per attachment to a
DBE. The record contains the fully qualified DBE name and its ATC file.
Each attached DBE will have an ATC file that contains the mapping
information required to access the TurboIMAGE database(s) to which it is
attached.
The IMAGESQL utility is used to attach and detach the DBE at the TurboDBs
(and to do some fine tuning of the mapping). In order to accomplish this,
you need to specify the TurboDB you want to attach and the Allbase DBE to
which you want to attach the TurboDB.
The detach in IMAGESQL gave you an error because you did not specify the
SQLDB with a SET command. I was thinking that even with the error it would
still detach from the DBE, but I realize now that is not possible.
(Actually, a few years ago and maybe 400,000 miles ago I would have
remembered that immediately.)
However, I knew that HP had added the command DETACH in DBUTIL for just the
circumstances that you were encountering. To wit, someone restored a
TurboIMAGE database, without the Allbase DBE or some variation on that
theme.
There is a flag in the TurboDB root file that says it is attached. If the
flag is set, the TC or TurboConnect file will be found as the file with the
root name + TC: (e.g., for MMSDB1 it would be MMSDB1TC). By using the
detach command in DBUTIL, you reset the flag and it also gave you the
message that the database had been connected to MMSDBSQ.PUB.TOL, because
that was the name it found in the TC file record. If there had been more
attachments, it would have listed those attachments as well.
At any rate, even though it gave you that error, it still reset the flag in
the root file and since Adager is a properly written application, it knew
about the flag and refused to go forward. Now that the flag has been reset,
Adager is quite content to work with your database, and that's how it should
be.
I cannot remember if the DBUTIL detach command will purge the TC file if it
is unable to detach from the DBE. You might want to do a LISTF on MMSDB1@
and see if the TC file is still there. It's been so long (12+ years), I
can't remember.
Lastly, in the future if you want to avoid this situation, you should used
IMAGESQL to detach from the DBE(s) before you do the store. However, that
may prove impractical, especially if you have done further mappings. Which
is why DBUTIL was enhanced to add the DETACH command. On the other hand,
you could get your hands on the utility DBTSQL that I wrote in 1993 to
preserve the mappings and recreate them after a detach/attach cycle. It is
freeware. It has a number of useful features such as listing the various
mappings and attachments, and letting you change passwords and such.
If you can't find it at Jazz, let me know. I have it here somewhere.
Denys
-----Original Message-----
From: Jim Phillips [mailto:[log in to unmask]]
Sent: Friday, July 14, 2006 7:48 AM
To: [log in to unmask]; [log in to unmask]
Subject: RE: [HP3000-L] Store Error
--- Denys Beauchemin wrote:
> Yes, using IMAGESQL.pub.sys (did I get that name
> wrong yesterday?). Do a
> set turbodb with the name of the IMAGE base and then
> do a detach.
>
> You can also do that with DBUTIL using DETACH, IIRC.
Strangely enough, neither of these appear to work:
HP36385B B.G4.10 IMAGE/SQL Utility
FRI, JUL 14, 2006, 8:39 AM
(C) COPYRIGHT HEWLETT-PACKARD COMPANY 1993
>>set turbodb mmsdb1
>>detach
SQLDBE not set (ATCERR 32437).
HP30391C.10.01 TurboIMAGE/XL: DBUTIL (C) COPYRIGHT
HEWLETT-PACKARD COMPANY 1987
>>detach mmsdb1
Detach failed from
(ATCERR 32351)
However, going into Adager before doing the above to
make structural changes failed because of the DBE
attachment; however, after doing the above, Adager
works just fine. Go figure.
Thanks, Denys.
Jim
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
