HP3000-L Archives

February 2003, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Denys Beauchemin <[log in to unmask]>
Reply To:
Date:
Thu, 27 Feb 2003 22:09:57 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (81 lines)
After testing earlier this evening, if found that I wrote something that was
incorrect.  One can indeed either copy (I used DSCOPY) a DBECON with its
associated DBEFILEs (and in my case, I must not forget to either detach all
TurboImage databases before doing the copies or copy the ATC info file,) and
be able to use the newly cloned DBE.

The two problem areas (discounting a copied ATC file) have to do with the
log files and the users.  One can use the SQLUTIL utility's PURGEFILE
command to get rid of the log files that may have been cloned.  They are
useless since the log files are fully qualified inside the DBECON.  Next,
using ISQL as Kent has shown, one can create a new logfile.  The problem
Kent is having has to do with not having a user named MGR@AMCSDW5 declared
in the existing DBE.

There are two ways to fix this.  The simplest way is to declare a new user
with DBA capabilities BEFORE the cloning takes place.  The construct is
simple, it is the user name with an anpersand and then the account name.  So
in ISQL on the source DBE, it would be:
GRANT DBA TO MGR@AMCSDW5;
Then clone the DBE.

The other method, after the cloning, would be to log in as the original user
and go into ISQL and connect to the newly copied/restored database and
declare a new user at that point.  There are going to be MPE security issues
unless that user has SM, but since Kent has access to god.pub.vesoft, it's
not a problem.  Once connected to the cloned DBE, simply issue: the GRANT
command described above.

Sorry for the confusion, it had been some years since I have played with
ALLBASE/SQL.  They say memory is the second thing to go, I forget what the
first is.

Denys

-----Original Message-----
From: Denys Beauchemin [mailto:[log in to unmask]]
Sent: Thursday, February 27, 2003 4:50 PM
To: KENT WALLACE; [log in to unmask]
Subject: RE: ISQL copy from account.

There is far more to an SQL database that needs to be fixed when you copy it
across accounts.  Beyond the users, as you are finding out, the DBE keeps
track of the file names of the DBE in its tables.

It might be better to unload to external, create a target DBE and then load
that from external, unless there is a tool out there that will allow you to
copy the DBEs.

Denys

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On Behalf Of
KENT WALLACE
Sent: Thursday, February 27, 2003 4:29 PM
To: [log in to unmask]
Subject: ISQL copy from account.

I copy ISQL data base from one account to another.  Then I use MPEX to purge
the log.  Then to rebuild the LOG file I do this:

I use god from vesoft.  Pardon the reference to diety.  Now I am gettting
this error?

isql=> START DBE 'MURSDBE.DBE' NEWLOG
>     LOG DBEFILE MURSDBELOG1
>        WITH PAGES = 150000,
>        NAME = 'MURSLOG1';
User MGR@AMCSDW5 does not have DBA authorization.  (DBERR 2300)
isql=>


<< end >>
Thanks
Kent Wallace

* 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 *

ATOM RSS1 RSS2