[AccessD] Deployment Woes

Gustav Brock gustav at cactus.dk
Mon May 3 08:11:36 CDT 2004


Hi Mark

> This would be ideal, however the primary reason I need to split the database
> is precisely because the app modifies itself.  The database contains a
> dynamic report in which the properties are set during run-time in design
> mode.  This causes problems when two or more people are in the database.

Oh, indeed!

/gustav


> Another approach:

> If your app allows (does not write to or modify itself), split it in a
> frontend and backend and write-protect the frontend file (mark it as
> read only). This will cause zero change at the users' machines.

> /gustav


>> I need the weekend to think this over, but I'm open for suggestions.  Our
>> department currently utilizes an existing database which is not split.
>> There are an estimated 100 shortcuts to this database littered throughout
>> the department.  Do to a rising concern in "concurrency issues", I need to
>> split this db.  With such an ingrained dependency on the existing shortcut,
>> it was suggested that I utilize the existing db as nothing more than a
>> glorified .bat file starter to distribute the new FE and subsequently check
>> revision status.  This seems like an awful lot of overhead in order to
>> placate the existing user base, and obviously would increase start-up times.
>> What do you think?




More information about the AccessD mailing list