I am getting close to the point where I need to decide what strategy
to use for the EDB catalogue files.  Any advice welcome.  

I have a small suite of apps of which users may install and use any
combination.  The main app can be used in local mode or with
peer-to-peer database sharing on a LAN, the others will always be
local.

It seems I could have:

1)  a single Catalogue, probably in the <pf><MyCompany> folder .. but
then the Catalogue on each user's machine could be different even
with the same softare version <shrug>, or

2)  a Catalogue for each app, presumably in the
<pf><MyCompany><MyApp> folders.

3)  some other combo!

The possible complications are:

a)  I place several of the minor apps in a single folder!  Under
DBISAM all of those used memory tables so there was no Database
folder.  But under EDB I think I need either 'real' tables or
temporary tables in place of the memory ones so I need to do some
re-thinking.  The temporary tables do not seem to be in the Catalogue
so does the Catalogue for those apps actually need a databse (I
guess, yes, but with no tables)?

b)  When the main app is used in shared data mode, which Catalogue
will each instance use?  The local machine one?  If so it will need
to have the settings changed to point at the network share, if not,
um... I will need a way to locate and access the 'shared' Catalogue.

Yikes!

Malcolm

--

Malcolm


If users are sharing the data for an app - eg your main one - they must also share the catalog. You don't have any freedom of choice in that. The data for temporary tables, unless my memory has failed, is in the defined temporary directory. Unfortunately I have no idea where the necessary structure information is kept.

For the minor apps why not stick to memory tables and create a catalog on the fly in the temporary folder and then zap it when the app is closed?

Roy Lambert [Team Elevate]

Roy Lambert wrote:

> Malcolm
>
>
> If users are sharing the data for an app - eg your main one - they
> must also share the catalog. You don't have any freedom of choice
> in that.

I was afraid of that. Which means I need to put the Cat in the shared
data folder or the clients can't find it.  But then the dear users
can zappit.

> The data for temporary tables, unless my memory has
> failed, is in the defined temporary directory.

Yes, this I understand.

> Unfortunately I have
> no idea where the necessary structure information is kept.

Tim' trade secret.

>
> For the minor apps why not stick to memory tables and create a
> catalog on the fly in the temporary folder and then zap it when the
> app is closed?

Ah, I thought memory tables were replaced by Temp tables .. heads for
the Manual again...

But it is legal for certain of these mini apps to run at the same
time so I have to decide if they share a Cat or I split them into
different folders.  ...may still make sense to have a single 'real'
database for all of them and make each capable of creating/updating
that Cat and database.  Hmm...

>
> Roy Lambert [Team Elevate]

I will worry later about my other big concern which is how to allow a
user to restore a database from the previous year when the structure
was almost certainly different.  Some time ago, Tim did say a CatDiff
utility/function was on the 'list'.

Malcolm

--

Malcolm

>I was afraid of that. Which means I need to put the Cat in the shared
>data folder or the clients can't find it.

Not necessarily. It has to be a shared directory but not necessarily the data directory. What about in with the apps - its a problem with Vista if you stick to M$'s rules.

>But then the dear users
>can zappit.

They can do that wherever you try and hide it

>But it is legal for certain of these mini apps to run at the same
>time so I have to decide if they share a Cat or I split them into
>different folders. ...may still make sense to have a single 'real'
>database for all of them and make each capable of creating/updating
>that Cat and database. Hmm...

I'd probably go with memory tables and unless they need to share data with the main app create a catalog & database on the fly. Its dead easy.

>I will worry later about my other big concern which is how to allow a
>user to restore a database from the previous year when the structure
>was almost certainly different. Some time ago, Tim did say a CatDiff
>utility/function was on the 'list'.

I thought I had an answer, but I thought about it as I typed and the best response I can now come up with is OUCH.

Roy Lambert [Team Elevate]

Roy Lambert wrote:

>
> It has to be a shared directory but not
> necessarily the data directory. What about in with the apps - its a
> problem with Vista if you stick to M$'s rules.
>

I stick by their rules so the App folder is a no-no for sharing.  I
have even found that creating a share with my installer in the
commonappdata tree will fail in Vista if file and printer sharing is
off.

>
> I'd probably go with memory tables and unless they need to share
> data with the main app create a catalog & database on the fly. Its
> dead easy.
>
I like dead easy .. to be investigated as this will likely mean the
least change.
 
> > I will worry later about my other big concern which is how to
> > allow a user to restore a database from the previous year when
> > the structure was almost certainly different. Some time ago, Tim
> > did say a CatDiff utility/function was on the 'list'.
>
> I thought I had an answer, but I thought about it as I typed and
> the best response I can now come up with is OUCH.

This is a 'requirement' for me.  The apps are for sports events and
it is so much easier to set up for one if you can restore the
previous one and simply replicate the key data then tweak it for any
changes.  Also users like to restore other users' events and do their
own custom results, etc.  In my DBISAM 4 versions, users can easily
restore from a DBISAM V3 database of 3 years ago with a load of
subsequent database updates and it was not a big deal for me to get
that working seamlessly.  Maybe it will turn out to be less trouble
than I fear

At least the data structures are a lot less fluid now than a few
years ago .. but the International Federation will be doing its
4-yearly rules review this summer so who knows what will be thrown at
me!

Malcolm

--

Roy Lambert wrote:

>
> It has to be a shared directory but not
> necessarily the data directory. What about in with the apps - its a
> problem with Vista if you stick to M$'s rules.
>

I stick by their rules so the App folder is a no-no for sharing.  I
have even found that creating a share with my installer in the
commonappdata tree will fail in Vista if file and printer sharing is
off.

>
> I'd probably go with memory tables and unless they need to share
> data with the main app create a catalog & database on the fly. Its
> dead easy.
>
I like dead easy .. to be investigated as this will likely mean the
least change.
 
> > I will worry later about my other big concern which is how to
> > allow a user to restore a database from the previous year when
> > the structure was almost certainly different. Some time ago, Tim
> > did say a CatDiff utility/function was on the 'list'.
>
> I thought I had an answer, but I thought about it as I typed and
> the best response I can now come up with is OUCH.

This is a 'requirement' for me.  The apps are for sports events and
it is so much easier to set up for one if you can restore the
previous one and simply replicate the key data then tweak it for any
changes.  Also users like to restore other users' events and do their
own custom results, etc.  In my DBISAM 4 versions, users can easily
restore from a DBISAM V3 database of 3 years ago with a load of
subsequent database updates and it was not a big deal for me to get
that working seamlessly.  Maybe it will turn out to be less trouble
than I fear

At least the data structures are a lot less fluid now than a few
years ago .. but the International Federation will be doing its
4-yearly rules review this summer so who knows what will be thrown at
me!

Malcolm

--

Malcolm,

<< 3)  some other combo! >>

My recommendations are usually this:

1) Put the configuration file in the same directory as the application.

2) Put the database(s) for a particular application under the main
configuration directory as \db1, \db2, etc.

<< a)  I place several of the minor apps in a single folder!  Under DBISAM
all of those used memory tables so there was no Database folder.  But under
EDB I think I need either 'real' tables or temporary tables in place of the
memory ones so I need to do some re-thinking. >>

No, you can still use in-memory databases in EDB.

<< b)  When the main app is used in shared data mode, which Catalogue will
each instance use?  The local machine one?  If so it will need to have the
settings changed to point at the network share, if not, um... I will need a
way to locate and access the 'shared' Catalogue. >>

Any application which shares a database will need to have the shared
database in a location that is accessible by all users using the same path
(UNC or drive-letter mapping).

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>
> 1) Put the configuration file in the same directory as the
> application.

So, one config per app. I can manage that.

>
> 2) Put the database(s) for a particular application under the main
> configuration directory as \db1, \db2, etc.
>

But that is under <pf> so is a problem for shared access

> << a)  I place several of the minor apps in a single folder!  Under
> DBISAM all of those used memory tables so there was no Database
> folder.  But under EDB I think I need either 'real' tables or
> temporary tables in place of the memory ones so I need to do some
> re-thinking. >>
>
> No, you can still use in-memory databases in EDB.

Cool

>
> << b)  When the main app is used in shared data mode, which
> Catalogue will each instance use?  The local machine one?  If so it
> will need to have the settings changed to point at the network
> share, if not, um... I will need a way to locate and access the
> 'shared' Catalogue. >>
>
> Any application which shares a database will need to have the
> shared database in a location that is accessible by all users using
> the same path (UNC or drive-letter mapping).

That I understand and already do under commonappdata .. my question
was about the config file, which, if it is to be shared by p2p
'clients', will most likely have to be in the database folder.  At
present I don't think I want to ease my life by lumbering my users
with a F/S setup.



--

Roy,

<< If users are sharing the data for an app - eg your main one - they must
also share the catalog. You don't have any freedom of choice in that. The
data for temporary tables, unless my memory has failed, is in the defined
temporary directory. Unfortunately I have no idea where the necessary
structure information is kept. >>

The metadata for temporary tables is kept in memory.

--
Tim Young
Elevate Software
www.elevatesoft.com

Malcolm,

<< But that is under <pf> so is a problem for shared access >>

In the case of Vista or shared, make the configuration/app path be a shared
folder or a folder in the local Application Data folder.  But, the principle
of having the database paths be under the configuration path is still
suggested.

<< That I understand and already do under commonappdata .. my question was
about the config file, which, if it is to be shared by p2p 'clients', will
most likely have to be in the database folder. >>

Not necessarily.  Again, I usually recommend that you keep the configuration
file/log *out* of any database directories.  It's simply just too easy to
think that you're blowing away the contents of a single database with an:

erase *.*
or
move *.* \someotherdir

and end up killing/messing up the entire configuration in the process also.

--
Tim Young
Elevate Software
www.elevatesoft.com