Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.

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"


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.)

asked 16 Feb '11, 20:36

Volker%20Barth's gravatar image

Volker Barth
accept rate: 34%

edited 17 Feb '11, 10:58

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().


permanent link

answered 16 Feb '11, 21:22

John%20Smirnios's gravatar image

John Smirnios
accept rate: 37%

Well, the question came up on Breck's current blog article (cf. the comments on 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:)

(17 Feb '11, 08:33) Volker Barth
Comment Text Removed

@Volker: FWIW GetModuleFileName() is different from the API that didn't work for me (GetCommandLine), so it's not clear that the same problem exists for it.

(17 Feb '11, 10:39) Breck Carter

@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.

(17 Feb '11, 10:51) Volker Barth

@Breck: I've used that technique in own code (not a SQL Anywhere DLL) - but I guess my product suggestion makes sense, doesn't it:)

(17 Feb '11, 10:53) Volker Barth

@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:)

(17 Feb '11, 10:58) Volker Barth

As Karim noted, I was suggesting a regular external function -- not an external environment.

(17 Feb '11, 15:35) John Smirnios
More comments hidden
showing 4 of 6 show all flat view

@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.

permanent link

answered 17 Feb '11, 12:36

Karim%20Khamis's gravatar image

Karim Khamis
accept rate: 40%

OK, yes, then it would defintely be quite simple. But then it would need to fit the server's bitness, and the original problem that raised this question (cf. Breck's blog) was to get rid of bitness-specific DLLs by using an external environment...

(17 Feb '11, 13:50) Volker Barth

The server should scan for the DLL with the specified name with the correct bitness if that is not already happening. The EXTERNAL NAME clause should probably be changed to allow a different explicit path to be provided for each bitness too: "Win32:...;Win64:...".

(17 Feb '11, 15:34) John Smirnios

@John: So you suggest (or plan?) to extend the syntax (currently only used to distinguish Unix from Windows calls) to differentiate between 32 and 64 bit versions, too (like in the oooold days with Windows95, Windows3X)? - That's a good and reasonable idea IMHO.

(18 Feb '11, 11:22) Volker Barth

Nevertheless, I still think such a general thing as the database engine's path should be easily accessable via a server property.

(18 Feb '11, 11:25) Volker Barth

@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:

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.

(18 Feb '11, 15:00) John Smirnios

@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.

(18 Feb '11, 15:07) John Smirnios
More comments hidden
showing 5 of 6 show all flat view
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 16 Feb '11, 20:36

question was seen: 3,161 times

last updated: 17 Feb '11, 12:36