I'm automating archiving/deleting data (note archiving is not a backup but moving data from live to archive table) and if data is moved or deleted then optimising the table.

Since this is part of a larger app and a variety of tables may or may not be open I need to figure out the best way of handling it.

Closing all tables is no problem (a simple session.close will take care of it) but reopening the ones that were active before the optimising started it a bit more difficult.

I think I can do it by looping round all forms and datamodules and building a list of those that were active and then run through it afterwards opening the appropriate ones.

Can anyone suggest a better way?

Roy Lambert

Roy,

> I think I can do it by looping round all forms and datamodules and building a list of those that were active and then run through it afterwards opening the appropriate ones.
> Can anyone suggest a better way?

You could try to open each table with exclusive access and trap the
error if it's already active. Thus you have a quick list of all open
tables regardless where in your app they have been opened.

Uli

Uli

>You could try to open each table with exclusive access and trap the
>error if it's already active. Thus you have a quick list of all open
>tables regardless where in your app they have been opened.

I could but then if I have the same table open in two places (ie two TEDBTable components) it wouldn't detect that.

Roy Lambert

Roy,

You need a list of your active tables, but I do not think such list exists, so you will probably have to build one yourself.  I can think of only
two ways to do that. If you do not want to scan for Active datasets and source code is available then you can probably make themselves
registered/unregistered in the process which handles activation/deactivation. Without source you could try to create your custom
components and assign a trigger to the AfterOpen and AfterClose events to handle registering/unregistering the datasets to your list.
Generally I find it to be a useful practice to start by creating a custom version of a component I am beginning to use.  Some
customization cannot be done this way, but it does not require reimplementing your changes every time the new version comes out.    

Leslie

Leslie


That's a nice approach, and since I'm already customising the table component will only need a little extra work.

Roy Lambert

Roy,

if I understand your problem and the EDB documentation in right way there is
a the TEDBDatabase.datasets[index: integer] property which gives exactly
what you want: 'The DataSets property provides an indexed array of all
active datasets for a TEDBDatabase component.  An active dataset is one that
is currently open.'

Regards
Iztok Lajovic



"Roy Lambert" <roy.lambert@skynet.co.uk> je napisal v sporoèilo
news:84156DFB-7284-4C2A-BA79-E6C5B2926B87@news.elevatesoft.com ...
> I'm automating archiving/deleting data (note archiving is not a backup but
> moving data from live to archive table) and if data is moved or deleted
> then optimising the table.
>
> Since this is part of a larger app and a variety of tables may or may not
> be open I need to figure out the best way of handling it.
>
> Closing all tables is no problem (a simple session.close will take care of
> it) but reopening the ones that were active before the optimising started
> it a bit more difficult.
>
> I think I can do it by looping round all forms and datamodules and
> building a list of those that were active and then run through it
> afterwards opening the appropriate ones.
>
> Can anyone suggest a better way?
>
> Roy Lambert

Iztok


Good try, and it was my first thought, but that property simply returns a list of tables in the database. If there are several components pointing at the same table that information will be lacking.

Roy Lambert

Roy,

<< Good try, and it was my first thought, but that property simply returns a
list of tables in the database. >>

No, it returns a list of all TDataSet descendants that are attached to a
particular database.  You can use the TEDBSession.Databases property
(DatabaseCount gives the count) to get a list of the TEDBDatabase
components, and then the DataSets property for each TEDBDatabase to get the
list of TEDBTable, TEDBQuery, TEDBStoredProc, and TEDBScript components that
are accessing each database (and are active or not).  The added bonus is
that this information also gives you the exact components that you need to
save the state for.

http://www.elevatesoft.com/manual?action=mancompprop&id=edb2&product=d&version=7&comp=TEDBSession&prop=Databases

--
Tim Young
Elevate Software
www.elevatesoft.com

My apologies to Iztok, I obviously didn't read his post correctly, or dig down to the correct property before.


Roy Lambert

"Tim Young [Elevate Software]" wrote:

Roy,

<< Good try, and it was my first thought, but that property simply returns a
list of tables in the database. >>

No, it returns a list of all TDataSet descendants that are attached to a
particular database.  You can use the TEDBSession.Databases property
(DatabaseCount gives the count) to get a list of the TEDBDatabase
components, and then the DataSets property for each TEDBDatabase to get the
list of TEDBTable, TEDBQuery, TEDBStoredProc, and TEDBScript components that
are accessing each database (and are active or not).  The added bonus is
that this information also gives you the exact components that you need to
save the state for.

http://www.elevatesoft.com/manual?action=mancompprop&id=edb2&product=d&version=7&comp=TEDBSession&prop=Databases

--
Tim Young
Elevate Software
www.elevatesoft.com


So the list actually does exist and it seems so obvious now where to look for it.