It has been my experience with SQL that the creation of the DB instance
itself is almost proprietary, but the code to create the elements of the DB
are for the most part universal. Flat files for every aspect of the SQL DB
creation can be created and used, but the trick is finding the documentation
to support your efforts. When the GUI front-ends of DB's came on the scene,
the knowledge of how to do it manually began to disappear.
Your best bet is to create the SQL DB and once it reflects what you want
from your Image data. Then upkeep both which is easier than a script
converter. We have such an animal we developed to go from Image to Oracle,
data and all, but it is tough because of naming differences and logic
shifts, for instance in our environment having multiple DB's separated logic
functions, but when we went to Oracle that was not the case. We had to
monkey with the Owner names of the objects to make them unique. Because in
Oracle you have a DB environment, whereas in Image you have the DB only with
a handle to each DB treated as a file handle.
Now before those who like Oracle tell me this is not true, this is how it
was when we began development and the new version of Oracle may not be
limited as such and we did not want to go into linking the DB environments
together, so I do not want to hear of other options in Oracle.
So back to my original point, once created, just keep both schemas, Image
and SQL, and modify both of them and apply the changes as needed. With SQL
this often times can be done online and quite easily. If either schema's get
out of sync with what is really there both environments usually have a way
in which a new schema can be recreated from the live DB.

        James

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
Behalf Of Tom Emerson
Sent: Tuesday, March 05, 2002 10:17 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] Does there exist...


> -----Original Message-----
> From: [log in to unmask] [mailto:[log in to unmask]]
>
> Best bet is to create your new SQL schema in a flat file and then:
>
> RUN DBSCHEMA.PUB.SYS < your_flat_file_name
>
You're missing the point (sort of) -- let me see if I can better explain...

I've grown up in the HP3000 "world" of databases whereby one ALWAYS uses an
editor to make a standalone IMAGE schema file and process via

   :FILE DBSTEXT=myschema
   :RUN DBSCHEMA.PUB.SYS;PARM=1  [or possibly 3 with DBSLIST redirected]

However the Microsoft "access" / unix "sql" way of doing things seems to be
"generate a database on the fly by running an interactive tool [access/isql]
and building/refining as you go..."

I am aware that (under unix/linux), you can build a "script" that contains
the commands you would type interactively and use

   $ isql < schema_creating_command_file

however there is a down side to this: if "half way" through the commands you
make a mistake [mistype a field name, use an incorrect "type" for a field,
or make an outright "syntax" error], isql will have "processed" half of your
file leaving a half-baked database on the system (i.e., recovery can be
messy) -- OTOH, DBSCHEMA won't process a file unless it is completely
correct from the outset...

[aside: the thought occurs, howevr, one could use "begin transaction"/"end
transaction" commands surrounding the creation of the tables, but that still
seems to be a kludge]

What I'd like to do is continue to make "completely correct" IMAGE schemas,
then process them through "this program" to create an input file for isql
that will create a "functionally" similar database using any "sql" type
database [admittedly, it won't be as robust as an image database, but we
gots to work with what we can get nowadays... :( ]

Does that make more sense?

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