Drew Jensen a écrit :
Hi Drew,
Do you mind if I ask why you put the form on the shared file server,
stand alone. If you are pushing copies of an odb file to the
workstations why not just have the form embedded in the odb file?
So - you can update the form without having to update all the odb file?
Yes, my forms were initially created in 1.x - the good old days ;-)
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).
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.
When Base 2.0 first came out, it was unstable on Linux, but on Mac it
was just a plain "no mans land" - you didn't want to go there. Another
example is font display - the way your form shows on the Mac isn't
necessarily the same as that on the Linux workstation, because font
handling is different. Base files are also still too prone, for my
liking, to write errors, which can leave the file at best in a state of
uncertainty, at worst unusable (lock file hell, anyone ?). 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). This also means that
everything that the user does or tinkers with in his work environment is
also saved to the NFS share. Unfortunately, there are still sporadic
bugs with NFS writes that can really screw things up, independent of the
OOo document type, but funnily enough only with OOo. So I'm paranoid and
try and limit the damage - at least I can prevent the form from being
mutilated with network server file permissions, and this solution has
proved itself to be the most stable so far over time. However, I would
love to see the day when I can just stick an ODB file on a file server,
and have it multi-session and multi-user, without screwing up. Then I
would put all of my eggs into one basket and just keep a few backup
copies in case the inevitable happened ;-)
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
