In EDBManager 2.15 Unicode I have a problem wherein the EDBConfig files are not created. I am using the Default session, and there are numerous other databases in that session.

In EDBManager I run...

CREATE DATABASE "MyApp"
PATH 'C:\ProgramData\MyApp\Version1\Data'
UNENCRYPTED CATALOG

...and it creates the folder 'C:\ProgramData\MyApp\Version1\Data', and the 2 files therein: EDBDatabase.EDBCat and EDBDatabase.EDBLck.

I run the following...
SCRIPT
BEGIN
EXECUTE IMMEDIATE 'CREATE TABLE "Client"
(
"ClientID" INTEGER GENERATED ALWAYS AS IDENTITY (START WITH 0, INCREMENT BY 1) NOT NULL,
"Name" VARCHAR(60) COLLATE "UNI_CI" NOT NULL,
etc etc
END
...and the EDBDatabase.EDBCat.Old is added to C:\ProgramData\MyApp\Version1\Data.

In EDBManager, I highlight the new table and click on 'Import' from a csv I expreted to earlier. Once that is done the Client.EDB* files appear in C:\ProgramData\MyApp\Version1\Data, but there are no EDBConfig files.

Ideally, the EDBConfig file should be in C:\ProgramData\MyApp\Version1, shouldn't it? It has been that way with other databases, but I can't remember how I did that.

How do I set up a new database?

Regards & TIA, Peter

Peter

I suspect that you're getting slightly confused between configuration and catalog files. The former is EDBConfig.EDBCfg and the latter EDBDatabase.EDBCat.

EDBConfig.EDBCfg  is the file that is created for the session and there is only one per session no matter how many databases. Its created when you first open the session and is located in where ever you set as the LocalConfigPath. If its a remote session its where ever the server has it stuffed.

EDBDatabase.EDBCat is created on the basis of one per database and is located in with the tables. Its where the PATH statement is set to.

What you seem to be saying, unless I'm getting confused, is that you've created another database in an existing session so what you're getting is exactly what I would expect.

Roy Lambert

Thanks Roy. I had taken too literally an assertion that I had read on the NGs that one only needs one session. While that is true, when the database is being created on a user's system, it does not need to refer to an unrelated database that existed on the developer's machine.

Simple fix, everything works a treat; thanks for your input.

Regards, Peter

Peter


Just to extend on a bit - databases within a session can talk to each other but sessions can't so the session is the mechanism for isolating data from other bits of data. This is either who cares,  useful or bloody annoying depending on what you're trying to do at the time.

As an example it would be nice if a local session and a remote session could communicate so you could have some centralised stuff and some stuff on the users PC happily working together.

The above only applies to SQL (queries, scripts and any etc there is) and not tables. Tables don't seem to care where they are which is very handy.

Roy Lambert