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?