Re: pgaccess - where to store the own data - Mailing list pgsql-interfaces

On Friday 30 August 2002 19:18, terry wrote:
> >>  Iavor Raytchev wrote:
> >>  > Hello everybody,
> >>  >
> >>  > There is an open question we need broad opinion on.
> >>  >
> >>  > Currently pgaccess stores its own data in the database it works
> >>  > with. Some people do not like that. To store it elsewhere invokes
> >>  > a number of issues such as:
> >>  >
> >>  > - where is this somewhere
> >>  > - converting form all versions to the new
> >>  > - etc.
> >>  >
> >>  > What do people think about this. Is it so bad that the own data
> >>  > is stored in the database pgaccess works with?
> >>
> >>  I don't particularly like it. Oracle deals with this by having a
> >>  database unto itself as a management repository (Oracle Enterprise
> >>  Manager, OEM, I believe). You register the database you want to
> >> manage with the repository, and the metadata is kept there instead
> >> of in each managed database.
> >>
> >>  Joe
>
> I would agree that pgaccess's metadata should not necessarily be stored
> in with <all> of the rest of the data being used by a pgaccess
> application.  However, having a central repository as described above
> may make it difficult to distribute an application without providing
> some capabilities to distribute/manage a portion of the central
> repository - which could be ugly for the developer and an end user.
>
> From my experiences using m$access to augment existing applications, I
> would think that at least two sets of data would need to be handled by
> pgaccess - some in an existing database, and some in the pgaccess
> application.  Hence, the structure of m$access with it's 'linked' and
> local tables in the application database itself.  For self-contained
> applications, no linked tables would be used, and the existing format
> is fine for distributing an application.  But, a major strength of
> m$access is it's ability to use data from multiple sources (databases),
> while the application database uses them transparently.
>
> In any case, where there are multiple users (say > 3 people) the data
> is usually separated from the application metadata anyway for
> maintenance purposes.  That way it is not necessary to do live changes
> or to pass large data laden databases about for an application
> modification.
>
> Hence, I would vote to retain the existing method, and put the effort
> into the ability to open multiple 'other' databases on a table by table
> basis.
>
> Regards,
>
> terry
===============

Well, I thought I was the only one that want to do that.

Please give this "linking" serious consideration. Maybe even the postgresQL
folks can help in this area.

I have used it in MS Access for 9 years, and it does work well.

Where there is a will, there is a way !
--
John Turner
JCI Inc.
http://home.ntelos.net/~JLT
"Just because you do not know the answer
does not mean that someone else does"
Stephen J. Gould, {rip}