At 06:05 PM 8/02/2005 +0200, you wrote:

>See previous thread: error upon connecting to database from remote client.
>
>Well I tried finding the solution. First by re-reading relevant chapters in
>The Firebird Book by Helen.
>Chapters 5, 6,7. Then appendix II pages 915 - 921
>
>The only way I could get it to work, was to share the Firebird folder over
>the network.
>Then I noticed it worked, and that an entry was placed in the firebird.txt
>file, showing a connect from a client had occurred. I think this is an error
>log.
>When this folder is not shared, then the client does not have permission to
>write to this file.
>
>Helen if you are out there: you do mention in your book that there can be
>problems with permissions on NTFS drives.

No, because it's not true. You should *not* try to share folders that
contain Firebird artifacts or databases.

>You don't' however anywhere recommend that the (and these are the files that
>required sharing) following be shared:
>Folder in which the database resides.
>Folder that Firebird is installed into.

No. Because you shouldn't.

>Temp folder in windows/system32/temp.

In the book I DO recommend that you explicitly set up temporary folders and
configure them but I certainly don't tell you to put them inside any of
Windows' own folders. I would be highly surprised if Windows allowed you
to access a folder under windows\system32.

You might help yourself a lot by doing the proper thing right off, rather
than assuming that Windows is going to let you have access to one of its
system artifacts.

>Surely none of these folders need to be shared on the network, nor do users
>need to have permission to write to them.

No.

>I would think that the SuperServer
>residing on the host machine, should be albe to handle any folder on the
>same server .. in my case the same hard disk, and that clients should not
>have share access to the default install directory of Firebird, nor to the
>database directory for that matter. What prevents them from just copying the
>database, or even worse just deleting it then.
>
>There must be more to this, and I'm really hoping for an answer.

Yes, you seem to be barking up the wrong tree entirely. Forget about
sharing: you will CAUSE problems by configuring things on shared
filesystems. This should be painted in the sky!!

>Server: Win XP Professional (Only because Boxed Suse Linux 9.2 would not run
>on the machine due to SATA problem .. have to wait for a new kernel that
>supports latest Intel motherboards.
>Clients: Mix of Win 2000, Win XP Professional.
>On all clients Firebird Client installed version 1.5.1.4880
>Firebird Super Server on Server PC: Version 1.5.1.4880
>Static IP addresses, due to a wireless router in the network that requires
>specific address range for internet access.
>Hosts file configured on each machine to contain localhost ip, and
>NEWSERVER ip
>Config default, except that added c:\temp 500000000 entry hoping this was
>the problem.

Well, does c:\temp actually exist on the server? Earlier, you were talking
of [sic] /windows/system32/temp [not a valid filesystem path on Windows,
anyway...] and below you are talking about similar (with a typo?)

>Gbak database transportable, then Gbak -c on the server machine.
>Now that all the folders mentioned below are shared across the network, with
>write permissions it all works:
>C:\Prax Database: C:\Prax\Prax.gdb
>C:\Program Files\Firebird Default install directory C:\Program
>Files\Firebird\Firebird_1_5
>C:\Temp
>C:\Windows\Systme32\Temp

Here we have another invalid file path; but not a good choice anyway: if
this path exists, it's sitting inside a privileged directory.

>Perhaps the answer lies in the following paragraph from Helen's book:
>"Does the Owner of the Server Process Have Sufficient Permissions To Open
>Files?" pg 918
>Helen .. how do I give the SERVER these write permissions on the same drive.

The owner of the server process in Windows is (by default) the LocalSystem
user, which has huge privileges. In short, unless you installed Fb 1.5 to
be owned by a different user than LocalSystem, permissions won't be the
problem.

Rethink. Create one or more blocks of sort space (i.e. directories) on the
server's hard disk, NOT inside things that the Windows system owns. For
example, assuming the server has one hard drive and one partition, create a
folder named fb_sortspace.

The, go to firebird.conf, get rid of whatever you have there for the
TempDirectories parameter and enter this:

TempDirectories = c:\fb_sortspace

If you want to, you can add a number that limits the amount of sort space
that can be used. The figure is in bytes and should not be higher than the
amount that is *actually* available.

Also, be aware that changes to firebird.conf don't take effect until you
shut down and restart the server.

I also recommend that you double-check your firebird.conf entry for typos.

./heLen