Subject | Re: [IB-Architect] Opening remote databases |
---|---|
Author | reed mideke |
Post date | 2000-08-25T23:35:01Z |
AlisdairM wrote:
fileservers that don't run the server. There are some, like
those from network apliance inc, that don't even run other software.
In that case, it >might< be reasonable to be able to tell the server
"I know this file is remote, but just trust me..."
It might be reasonable for the server to be able to detect if
the file was already in use by another server (but no need
to try to let two server ever actually work with it at the same
time)
--
Reed Mideke rfm(at)cruzers.com
If that doesn't work: rfm(at)portalofevil.com
InterBase build instructions: www.cruzers.com/~rfm
>The one scenario that does make some sense is high-performance
> The 2 main advantages I see for mouting on a remote drive are data
> sharing and centralised backup. Data sharing is out for the reasons
> above, which leaves backing up private databases. Again, IB provides
> separate tools that should be used for this is backing up the binary
> file is not the same as backing up the database. Neither scenario work
> well for a remotely-mounted local IB server.
>
fileservers that don't run the server. There are some, like
those from network apliance inc, that don't even run other software.
In that case, it >might< be reasonable to be able to tell the server
"I know this file is remote, but just trust me..."
It might be reasonable for the server to be able to detect if
the file was already in use by another server (but no need
to try to let two server ever actually work with it at the same
time)
> I beleive it would be doing the customers a disservice to make these[...]
> sorts of errors, although you may have another scenario I have
> overlooked that is more reasonable.
>
> AlisdairM
--
Reed Mideke rfm(at)cruzers.com
If that doesn't work: rfm(at)portalofevil.com
InterBase build instructions: www.cruzers.com/~rfm