Alex Thurgood wrote:
I want to maintain control of the form without the users having to be asked whether they need to save their file each time, beccause experience has shown that this leads to confusion, like doing a "save as, thinking that the data entered hasn't been saved (doh!!). If I embed the form in the ODB, I can not be certain that users will not open the form by mistake in design mode (it has happened) and wreak havoc (as also happened recently). The same is true of queries. I have yet to find a way of harmonising queries across the board, for example having a set query that the user can not then modify (other than within the limits of the parameters allowed).
What you are talking about is very much what many people mean when they ask about a "Switchboard" feature. ( Use of another jargon term...sorry ) What they are really saying with that, IMO from talking to a few about it, is to ask how the Base module handles the difference between the database application developer and the end users. Others users ask roughly the same question in a different way - "How do I create the runtime databases with Base?". They are really asking about the same set of features.
I suppose the real problem is one of least common denominator - we are in a heterogeneous environment, mostly Linux workstations, and a couple of Macs, and soon a Windows machine which will be configured appropriately, which of course has led to problems because of functionality mismatch (both in drivers and OOo functionality). I need my forms to remain unchanged by these "discrepancies", and unfortunately, there was (and still isn't btw) any guarantee of that. <snip> Our work place environment is setup so that when a user logs on, his desktop and other environment parameters are loaded from the user's NFS user directory (a bit like the Windows netlogon script). <snip>
Well, in a way you just made one of the arguments for why application servers came into being in the first place and why the shift to browsers for use as the UI engine instead of the traditional C/S rich client application. Scalability being another of the arguments of course. IMO however you ( your organization that is ) also speak to one of the issues with this solution, the other scale factor that comes into play - the size of the organization fielding these in house applications. There is a threshold that needs to be crossed in organization size before you are likely to find the in-house resources present to easily field these small database applications using that model. Although thee are definitely projects targeted to addressing this.
Drew --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
