You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Starting from Windows XP SP2, any user who calls CreateFileMapping in a session other than session 0 needs the "Create Global Objects" permission (in Local Security Policy)... When running Vista this means even an Administrative user needs to right click on the app that is using Firebird embedded and select "Run as Administrator" in order to avoid receiving such an error (since admin users in Vista also run in Session 1 when they login). This kind of defeats the purpose of using Firebird embedded databases in the first place (i.e. to simplify deployment).
This thread is talking about terminal services but I suspect it's more or less the same problem since in Terminal services users that login don't get assigned to session 0 either... In one of message Jason asks the following question:
I'm not sure if the embedded server needs to create global objects.
Would it be possible to use local objects under an embedded application
since only one process can have access to the database? Is there
something I can do when connecting to the Firebird database to not
use global memory objects?"
Dean's reply to this was:
It's hard to say, actually. Higher up on the page (in the lpName parameter
description) it says:
Terminal Services: The name can have a "Global\\" or "Local\\" prefix
to explicitly create the object in the global or session namespace\.
The remainder of the name can contain any character except the backslash
character \(\\\)\. Creating a file mapping object in the global namespace
requires the SeCreateGlobalPrivilege privilege\.
Obviously, for embedded, you only need it in the session namespace, and the
last sentence there implies that you DON'T need SeCreateGlobalPrivilege for
that to work. Some experimentation may be required...
All that being said, this code is actually just calling the native code in
fbembed.dll, so I'm pretty sure the error is in the database server and not
the .net provider.
At first glance, as I say not knowing anything about the internal workins of Firebird, it seems like a solution might be possible by opting either to create objects in the session namespace (if the connection string that was used specifies an embedded server) or the global namespace (if we're running firebird server).
I'd really like to use a Firebird embedded database but, as I say, I'm using it mainly to simplify deployment. The app I'm building is designed to be downloaded and installed by joe shmoes from the public at large and adding the requirement to explain to them that the app is not a normal app but a special "extremely hard to install app" that requires they go find their network admin and have him assign some custom privileges to their account is basically going to be a showstopper. Any chance of this being corrected in future versions?
The text was updated successfully, but these errors were encountered:
Submitted by: James Crosswell (james.crosswell)
Starting from Windows XP SP2, any user who calls CreateFileMapping in a session other than session 0 needs the "Create Global Objects" permission (in Local Security Policy)... When running Vista this means even an Administrative user needs to right click on the app that is using Firebird embedded and select "Run as Administrator" in order to avoid receiving such an error (since admin users in Vista also run in Session 1 when they login). This kind of defeats the purpose of using Firebird embedded databases in the first place (i.e. to simplify deployment).
I'm not sure if this is [easily] fixable - I'm completely ignorant of the inner workings of Firebird, but I came across the following thread in the mail-archive:
http://www.mail-archive.com/firebird-net-provider@lists.sourceforge.net/msg03563.html
This thread is talking about terminal services but I suspect it's more or less the same problem since in Terminal services users that login don't get assigned to session 0 either... In one of message Jason asks the following question:
I'm not sure if the embedded server needs to create global objects.
Would it be possible to use local objects under an embedded application
since only one process can have access to the database? Is there
something I can do when connecting to the Firebird database to not
use global memory objects?"
Dean's reply to this was:
It's hard to say, actually. Higher up on the page (in the lpName parameter
description) it says:
Obviously, for embedded, you only need it in the session namespace, and the
last sentence there implies that you DON'T need SeCreateGlobalPrivilege for
that to work. Some experimentation may be required...
All that being said, this code is actually just calling the native code in
fbembed.dll, so I'm pretty sure the error is in the database server and not
the .net provider.
At first glance, as I say not knowing anything about the internal workins of Firebird, it seems like a solution might be possible by opting either to create objects in the session namespace (if the connection string that was used specifies an embedded server) or the global namespace (if we're running firebird server).
I'd really like to use a Firebird embedded database but, as I say, I'm using it mainly to simplify deployment. The app I'm building is designed to be downloaded and installed by joe shmoes from the public at large and adding the requirement to explain to them that the app is not a normal app but a special "extremely hard to install app" that requires they go find their network admin and have him assign some custom privileges to their account is basically going to be a showstopper. Any chance of this being corrected in future versions?
The text was updated successfully, but these errors were encountered: