Hi, inspired by Tim's mails I am just evaluating EDB (till now using DBISAM3).

I don't understand a basic thing: in DBISAM I just used MyDatabase.directory := MyPath to
change the path of a Database.component.
How do I do this in EDB? Assuming I have 3 Databases that I want be able to move to
another directory, then connect to them by code.

Have I to change a cfg-file?

Sorry for this question, but I didn't find an explanation of these basic things in the manual.

Regards Uli

I used the time

... and found an example that answers my question. Thanks.

Regards Uli

Uli Becker,

I give my voice to you.  Changing the path of the database was a good thing especially when it comes to big applications with some Far-Away
customers.   Now I have to take care of lot things (INI-CNG).  I am sure Elevate could and should have some nice solutions.

Abdulaziz,

<< I give my voice to you.  Changing the path of the database was a good
thing especially when it comes to big applications with some Far-Away
customers.   Now I have to take care of lot things (INI-CNG).  I am sure
Elevate could and should have some nice solutions. >>

Let me see if I can put this in perspective.

With DBISAM, you had to maintain the database directory somewhere if you
wanted it to be persistent, and a lot of people just used an .INI file or
the registry.  Well, with ElevateDB, just think of the configuration file
(EDBConfig.EDBCfg) as that .INI file in terms of storing the database name,
description, and path.

But, instead of using registry or .INI manipulation code, you use simple
CREATE DATABASE, ALTER DATABASE, or DROP DATABASE statements using the
provided TEDBSession.Execute method for executing configuration-level SQL
statements for manipulating databases, users, etc.

Finally, the TEDBEngine.ConfigPath is the one and only setting that you need
to set that simply specifies where the configuration file is stored.

The rest of the database handling code is the same as with DBISAM in terms
of databases being tied to a specific database directory and the table files
residing in that directory.

Now, as to the benefits.  In DBISAM, you had to use directory names in SQL
statements if you were referring to a database in a different database
directory.  Furthermore, this caused some major issues with some 3rd party
applications like Crystal Reports when they tried to issue SQL against the
DBISAM ODBC Driver.  With EDB this is all gone.  Databases are always
referred to using a *logical* name, not a directory path, and the naming
conventions are standard SQL (DB.Schema.Table, where Schema is optional
unless querying the Information schema)  that are easily handled by
applications like Crystal Reports, etc.  And, converting an application from
local to client-server truly only requires one property change with
ElevateDB - changing the SessionType from stLocal to stRemote will do the
trick.  There's no more need for using the TDBISAMDatabase.Directory
property in some cases, and the TDBISAMDatabase.RemoteDatabase property in
others.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim, thanks for your detailed and convincing explanation. Please paste this into the
help-files. That would be very, very useful.

Best regards

Uli

Uli,

<< Tim, thanks for your detailed and convincing explanation. Please paste
this into the help-files. That would be very, very useful. >>

I'm going to start a series of blog-like articles on the web site in the
next month, and this will be one of the issues that I'll be covering in
detail.  Hopefully these articles will serve as a more in-depth backstop and
discussion regarding some of the areas of the product that aren't
immediately obvious.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> I'm going to start a series of blog-like articles on the web site in the
> next month, and this will be one of the issues that I'll be covering in
> detail.  Hopefully these articles will serve as a more in-depth backstop
> and discussion regarding some of the areas of the product that aren't
> immediately obvious.

Great!! Looking forward to reading and learning from those articles.

Best regards,
Fons

Tim


So you've finally succumbed to the Web 2.0 madness

Roy Lambert

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message :
<<Well, with ElevateDB, just think of the configuration file
(EDBConfig.EDBCfg) as that .INI file in terms of storing the database name,
description, and path.>>

I'm a DBISam user with a very vague understanding of EDB. It seems like I
might have misunderstood the purpose of the Config file in EDB . I was under
the impression that the config file was much like lock control file in the
BDE/Paradox engine where all installations of the BDE in a worgroup had to
point to the same lock control file.

The documentation that caused me to draw this conclusion was :

<<Quote from EDB 1.08 Manual category=4&topic=6>>
Note
It is very important that you do not have more than one instance of the
ElevateDB engine using different configuration files and accessing the same
database(s). Doing so will cause locking errors. All instances of the
ElevateDB engine must use the same configuration file if they will be
accessing the same database(s).<</Quote>>

My questions are then :

1. Do all installations of an EDB app in a LAN accessing the same database
( under file sharing Local) have to point to the same config file ? If so,
can this be done programmatically such that the end-user does not have to
bother with this. Or do we need to provide the end user with a means to
configure the path to the EDB config file in their own network enviroment
(much like BDE/Paradox) ?

2. Where would you typically place the EDB Config file ?  Program Folder,
APPData folder or Shared Documents folder ? Do all users need read and write
access to the config file ?


Thanks
Gregory Sebastian

<<I'm going to start a series of blog-like articles on the web site in the
<<next month, and this will be one of the issues that I'll be covering in
<<detail.  Hopefully these articles will serve as a more in-depth backstop and
<<discussion regarding some of the areas of the product that aren't
<<immediately obvious.

<<--
<<Tim Young
<<Elevate Software
<<www.elevatesoft.com

Tim,

I just "converted" my first dbisam 3.30 app from file sharing to client server (also 3.30).
I played a little bit with EDB before.
I think the step from dbisam 3.30 file sharing to EDB (even in file sharing) is pretty big.
The step from dbisam 3.30 CS to EDB is more obvious.
With EDB weither you use it as CS or file sharing, you MUST use the same configuration files.
Maybe you could elaborate on that aspect in one of your blogs and get more users to upgrade.