on 2011 Feb 16 8:36 PM
Since V9, there is that property CommandLine to the database server's command line.
However, it just returns the program arguments but does not contain the executable's path.
For example, on my box, the returned value for the SA 12 demo database is similar to
"-c 8M -n demo C:\\...\\demo.db"
Question:
Is there a way to get the executable's path, too?
If not, I would like to suggest such a property.
(Workarounds seem not that easy, cf. my comments on John's answer.)
Request clarification before answering.
I don't see any property that would give you the executable's path but on Windows you could do it with an external function that calls GetModuleFileName().
-john.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Well, the question came up on Breck's current blog article (cf. the comments on http://sqlanywhere.blogspot.com/2011/02/loading-32-bit-versus-64-bit-dlls_16.html). And there's the problem: These Win32 APIs won't work when used from a DLL running in an external C/C++ environment. If I understand the API documentation correctly, it won't give me a module handle to the server's process when called from a different process. - I'd add a product suggestion:)
@Breck: I just checked a bit more, and I was wrong: You can also use GetModuleFileName() with a handle of a different process (as you will need when inside an external environment). The PSAPI will help here. You might enumerate and open all processes with EnumProcesses() and OpenProcess(), then use EnumProcessModules() to get all module handles of the opened process, and then use GetModuleBaseName() and the server's version and the IsNetworkServer() property to look for a module named dbengX/dbsrvX, and once you find such a handle, THEN you can call GetModuleFileName() to get the full path.
@Breck: Just to add: 1. Obviously that code works just on the server's box (but that's o.k. for an external function). 2. In case the box runs several engines of the according version installed in different locations (e.g. one of an OEM install) - well, then you might get the wrong file path. - Just a little bit of paranoia:)
@Volker: John's suggestion was to use an external function but have it loaded by the server rather than run it in an external environment. So basically your CREATE FUNCTION statement would not have a language clause. If you wrote such a function, then calling GetModuleFileName should work since the loading module is the server.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Volker: I'm not "planning" anything yet but can log suggestions as enhancement requests. I looked at the code and we essentially use LoadLibrary without scanning for a DLL with the correct bitness first. So we are at the mercy of Windows search rules: http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx
It seems that Windows always loads DLLs from the same directory as the app first. If you are embedding SA, just put the correct bitness of the external function in the same directory as dbeng/dbsrv and you should be fine.
If not embedding, finer control would be desirable.
@Volker: Getting the server's executable path seems like a reasonable suggestion. As it stands, I don't think we have found a way to get the executable's path on AIX yet though.
User | Count |
---|---|
82 | |
29 | |
9 | |
8 | |
7 | |
7 | |
7 | |
6 | |
6 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.