Hi All,

This is a general question and I guess there many answers, but how does
everyone else prefer to deploy their database in a new install?

Do you include the physical empty database files ?

Or maybe you have code in the app to create the blank database structure?

Or maybe you have another method?

I'd be interested to hear different methods.

Thanks,

Phil.

Phil,

> Or maybe you have another method?
> I'd be interested to hear different methods.

I ship the catalog-file together with my application. After the user has
chosen the directory where he wants to store his data, my application
first checks, it there is an existing database. If not, it just copies
the catalog-file into the database-dir.

When the user starts the application and the tables are opened, EDB
automatically creates empty tables from the catalog.

Uli

Phil,

> This is a general question and I guess there many answers, but how does
> everyone else prefer to deploy their database in a new install?
> Do you include the physical empty database files ?
> Or maybe you have code in the app to create the blank database structure?
> Or maybe you have another method?

We use following approach:

- all our applications are stored in common directory, in our case named
'kres' (name of our company) and directory 'kres' must have all privileges
for all users because the applications handle the users' privileges by
themselves (otherwise the access problems arise)

- there is a common subdirectory 'EDB' where the configuration file is
placed

- each application has its own subdirectory named <application name> and
this subdirectory has two subsequent subdirectories <archives> and <data>

- if particular application is used for managing data of different domains
(= business data for different companies) then for each of companies in
directory <data> the subdirectory <domain name> is created for each domain,
otherwise the data are stord in <data> subdirectory

- databaseName of each application is '<application name>-<domain name>'  or
only '<application name>' if there is no need for domains

- every application has embedded code for catalog creation in <EDB>
directory if there the configuration file is missing and the code for
database named '<application name>-<domain name>' creation if it is not yet
created and all code for creation of all files that must be in particular
database

- the code for file creation has all necessary information to upgrade the
tables if the table restructure took place in time when the application has
already been put in use.

- initial code for table creation is made on reverse-engineering code basis
supplied by Tim in edbmgr and by use of our program thyat we made for
transformation of reverse-engineering code to use in Delphi program. The
program can be found in'elevatesoft.public.elevatedb.extensions' group (last
entry).

All description ir rather long but I put it here in whole to describe our
approach to application deployment.

Regards
Iztok Lajovic
KreS, Kreativni sistemi, d.o.o.

Phil,

I have an .ini file that contain the structure and indexes of tables like this:

[Tablas]
Tabla1  = FormasPago
Tabla2  = Familias
.
.


[FormasPago]
Campo1  = CODIGO,C,2,
Campo2  = NOMBRE,C,30,

Indice1=CODIGO,CODIGO,""

[Familias]
Campo1 = CODIGO,C,3,
Campo2 = DESCRIPCIO,C,30,

Indice1=CODIGO,CODIGO,""
Indice2=DESCRIPCIO,DESCRIPCIO,""

.
.
.

I have a procedure that read this file .ini and if the table exists update and if not
exists create it.

This is very comfortable because when you want to modify or create tables only must to
modify the .ini file and execute the procedure to update all tables with new structure.

Hi,

I just started with EDB and I'd really like to have the same that I was
able to do with DBISAM. That is:

I have a script that defines all the tables, all physical/computed
fields,  tables,  indexes (with EDB I started to add constraints and
more will come I'm sure), startup demo data, configuration protected
data, etc. The script allows to define reporting elements, like for a
column: report heading, summary footer, formats, lengths min-max, etc.
The script is compiled as a resource and is contained in the .exe. It
could also sit in the application folder thus overriding the internal
resource. This is useful when you have users that need different data
size than what you thought was enough. (It may be a good idea to
encrypt the script but I never did it)

Anyway, when program starts first time it would ask where the database
is and after this stuff is resolved, it will automatically create the
tables (local|remote). Next time it starts, it checks each physical
table structure against the "logical" structure that's compiled in the
exe and if necessary automatically restructure any table that changed
(oh yes, the tables changes a lot in the first year or 2 of a new
application). The database location is stored in the .ini file. I don't
use the registry for anything.

The "scripting engine" supports external files, merging, allowing user
to setup its own data sizes/lengths/language. It supports aliases for
often used data so, for example, instead of explicitly selecting values
for a phone-like field, you'd select DOM_TELFAX and there you go, all
phone numbers in various tables will be stored the same way.

Also, I have a script wizard application which allows me to friendly
design the database and which also does write for me a lot of template
code.

That's about it ... probably I forgot some features. Now all this is
being adapted for EDB, I'm almost done except for the run-time check
and restructuring part.

Lucian

Lucian,

> The "scripting engine" supports external files, merging, allowing user
> to setup its own data sizes/lengths/language. It supports aliases for
> often used data so, for example, instead of explicitly selecting values
> for a phone-like field, you'd select DOM_TELFAX and there you go, all
> phone numbers in various tables will be stored the same way.

Any chance that you would be willing to share your "scripting engine"?  I'm
currently in the process of working on something similar and it would be
great to get something already working.

--

---------------------------------------
 Terry Swiers
 Millennium Software, Inc.
 http://www.1000years.com
 http://www.atrex.com

 Atrex Inventory Control/POS -
    Big business features without spending big business bucks!

Atrex Electronic Support Options:
 Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp
 Email: mailto:support@atrex.com
 Newsgroup: news://news.1000years.com/millennium.atrex
 Fax: 1-925-829-1851
 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
 ---------------------------------------

I second that Lucian, would you be willing to share the scripting engine?

Thanks,

Phil.



Terry Swiers wrote:
> Lucian,
>
>> The "scripting engine" supports external files, merging, allowing user
>> to setup its own data sizes/lengths/language. It supports aliases for
>> often used data so, for example, instead of explicitly selecting values
>> for a phone-like field, you'd select DOM_TELFAX and there you go, all
>> phone numbers in various tables will be stored the same way.
>
> Any chance that you would be willing to share your "scripting engine"?  I'm
> currently in the process of working on something similar and it would be
> great to get something already working.
>

> I second that Lucian, would you be willing to share the scripting
> engine?

The thing is I can't find a suitable way of sharing something
compilable without posting a lot of adjacent code which I don't want
(or can't) to share.

I think I could share some code that does not compile at first and
supply missing stuff on a case-by-case basis so that I won't be
open-sourcing stuff that I might intend to sell sometime. I would do
this thing with the condition that I could get back improved versions
of this stuff .... because it seems I underestimated the time it would
take me to finish (spare-time is something rare here).

There are two things I am currently after: the on-fly restructuring
(when the script changes) and a new wizard. The most important being
the restructuring.

What do you think?

Lucian Radulescu wrote:
>> I second that Lucian, would you be willing to share the scripting
>> engine?
>
> The thing is I can't find a suitable way of sharing something
> compilable without posting a lot of adjacent code which I don't want
> (or can't) to share.
>
> I think I could share some code that does not compile at first and
> supply missing stuff on a case-by-case basis so that I won't be
> open-sourcing stuff that I might intend to sell sometime. I would do
> this thing with the condition that I could get back improved versions
> of this stuff .... because it seems I underestimated the time it would
> take me to finish (spare-time is something rare here).
>
> There are two things I am currently after: the on-fly restructuring
> (when the script changes) and a new wizard. The most important being
> the restructuring.
>
> What do you think?


The restructuring part would be a godsend. Like you said.... the
database structure changes a LOT in the early stages of the design.  I
am holding off on releasing my first beta-release to my beta sites
because I'm worried about having to harass them with minor changes to
the database.

Dale