[AccessD] Deployment Woes

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.



Mark


-----Original Message-----
From: Gustav Brock [mailto:gustav at cactus.dk] 
Sent: Saturday, May 01, 2004 6:29 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Deployment Woes


Hi Mark

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?

-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com