>> 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
