Hello

I have a large project (190 forms, 130 tables, 380 procedures) that uses a single DataModule that contains the EDBEngine, EDBSession and an EDBDatabase.

The dynamically created forms often contain an EDBStoredProcedure component, in which the DatabaseName property defaults to the name I selected in the IDE, "Production".

Now I have been asked to create a "Practice" database, to allow users to learn how to use the app without damaging the real data in the Production database. With that database created and populated, I must now redirect the DatabaseName and Database properties of the EDBEngine and EDBDatabase components to the "Practice" database.

Piece of fruit, as all the EDBEngine variables are loaded from an INI file at startup, and set before the EngineBeforeStart. I intend to use an external app to allow the user to switch from “Production” to “Practice”, and save that choice to the main app’s INI file.

But, if a form is opened, and it contains an EDB datasource component, it naturally opens the DatabaseName that was set in the IDE - "Production".  I can reset the DatabaseName and Database properties of the embedded datasource components in the OnCreate of every form, but there are dozens of them, and I am lazy.

Is there a different strategy that I could or should use?

Regards & TIA

Peter

Peter


I'm slightly puzzled here. The databasename should point to the database component on the datamodule. The database component points to the disk location of the data. Unless you're altering the databasename of the database component there should be no problem.

I have applications where the user can select the database in use when they open the application. Engine, session, database all retain they same name just point to different data. Allowing users to flip between live and practice databases with the application open is a little more tricky, and, in my opinion, bad practice.Its far to easy to get confused as to where you are.


Roy Lambert

<<Unless you're altering the databasename of the database component there should be no problem.>>

Roy

I am changing those properties. That value is picked up from the INI file, and I set both the EDBDatabase1.Database and EDBDatabase1.DatabaseName to 'Practice' or 'Production'.

The Path to the config files remains unchanged - both databases are in the config tables.

Is there an alternative way to redirect to the appropriate database?

Regards

Peter

Peter wrote:

<<I can reset the DatabaseName and Database properties.>>

No I can't; the Database property of the EDBStoredProcedure is ReadOnly. But I can set the DatabaseName property of each EDBStoredProcedure, which works well, but involves a lot of work.

Maybe I should use two config file sets, each with a single database. Then I could just set the path to the appropriate config files, as Roy suggests. There is no real reason why the 2 databases should exist in the same config files - I just thought that that was how things were done.

Peter

Peter

R
>I am changing those properties. That value is picked up from the INI file, and I set both the EDBDatabase1.Database and EDBDatabase1.DatabaseName to 'Practice' or 'Production'.
>
>The Path to the config files remains unchanged - both databases are in the config tables.

I think you're getting slightly confused with the properties.

DatabaseName
TEDBDatabase component. The database name is arbitrary and is used only for identification of the
database when connecting TEDBTable, TEDBQuery, and TEDBStoredProc components. It is best to think
of the DatabaseName as an alias to the actual database, which is represented by the Database property.
The DatabaseName property must begin with an alpha character.

Database
Use the Database property to specify the actual ElevateDB database that will be accessed by this
TEDBDatabase component.

Or in Royspeak

DatabaseName
Used to tell tables etc which database component to use for the session selected

Database
Used to tell the database component which of the actual databases on disk to use OR used to tell the database component the path to the data on disk

TL;DR - with your system set up with the databases sharing a config file all you need to change is the Database not the DatabaseName

Roy Lambert

Roy

If I add a second EDBDatabase to the DataModule I still need to re-assign the EDBStoredProcedure1.DatabaseName property of every such component in the project. In fact, I would have to add a global property (e.g. IsPractice) that would determine which EDBStoredProcedure1.DatabaseName property to select.

It appears there is no way around setting all those component properties, which I accept.

Thanks Roy

On 20/01/2017 3:16 PM, Peter wrote:
> Roy
>
> If I add a second EDBDatabase to the DataModule I still need to re-assign the EDBStoredProcedure1.DatabaseName property of every such component in the project. In fact, I would have to add a global property (e.g. IsPractice) that would determine which EDBStoredProcedure1.DatabaseName property to select.
>
> It appears there is no way around setting all those component properties, which I accept.
>
> Thanks Roy
>

Peter

By accepting, you are creating a bunch of unnecessary work!

Roy is absolutely right!

Use the Database property to specify the actual ElevateDB database that
will be accessed by this TEDBDatabase component.

My application is used access 50+ databases and to change the database I
just change the Database property in just one TEDBDatabase that is in my
datamodule - that's all there is to it.

Cheers

Jeff

Jeff

<<Roy said: all you need to change is the Database not the DatabaseName>>

Aaaaaah, I get it. I thought that Roy was referring to the Database and DatabaseName properties of the EDBStoredProcs.

I have followed your advice and set *just the DataModule.EDBDatabase1.Database property;  anything else is unnecessary.

Thanks to both of you - you saved me a truckload of work

Regards

Peter

Peter


>Aaaaaah, I get it. I thought that Roy was referring to the Database and DatabaseName properties of the EDBStoredProcs.

Slightly difficult that

EDBStoredProcs (just had a quick check here) does not have a database property

>Thanks to both of you - you saved me a truckload of work

That's good.

Now this is not the way to go in this case but remember you can do things like this

procedure TContactsForm.ExecuteRefreshRequest(var Message: TMessage);
var
Cntr: integer;
begin
Contacts.Refresh;
ContactIDChange(Self);
for Cntr := 0 to ComponentCount - 1 do begin
 if (Components[Cntr] is TnlhDBGrid) and TnlhDBGrid(Components[Cntr]).DataSource.DataSet.Active
  then TnlhDBGrid(Components[Cntr]).DataSource.DataSet.Refresh;
end;
end;

So all you need is one small routine that you call. In your case you'd pass the form as a parameter, and even if you have a lot of forms to change you can create a base form to inherit from and then since Delphi forms are text based its dead easy to chenge them from inheriting from TForm to inheriting from TMyNewForm

Roy Lambert

Roy Lambert wrote:


<<procedure TContactsForm.ExecuteRefreshRequest(var Message: TMessage);>>

Just curious, is that activated by a timer, a EDBDBDataSet.AfterPost or does it respond to some form of database Notification?

Regards

Peter