tag:blogger.com,1999:blog-497787815177352569.post3620665412206641824..comments2024-01-03T08:55:04.827-05:00Comments on SQL Anywhere: Loading 32-bit Versus 64-bit DLLs [revisited]Breck Carterhttp://www.blogger.com/profile/15975598564711761434noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-497787815177352569.post-13190485516123368462011-02-16T05:18:46.974-05:002011-02-16T05:18:46.974-05:00Oh, never leave a comment without testing one'...Oh, never leave a comment without testing one's advice...<br /><br />That property (introduced in V9) only returns the command line arguments, i.e. it doesn't return the database engine's file path).<br /><br />So that may not be exactly what you're looking for.<br /><br />Regards<br />VolkerAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-497787815177352569.post-73476978472335395642011-02-16T05:00:44.621-05:002011-02-16T05:00:44.621-05:00Breck, YABC (yet another blog comment):
In this p...Breck, YABC (yet another blog comment):<br /><br />In this particular case, I agree that the external process behaves totally different than an internal DLL (for obvious reasons).<br /><br />But wouldn't the standard *property('CommandLine')* give you the wanted result from within the engine?<br /><br />Something you could then<br />a) fetch in the server and set in the DLL via a particular API like SetSrvCommandLine() or<br />b) fetch inside the DLL (using the EXTFN_CONNECTION_HANDLE_ARG_NUM handle)?<br /><br />Just a few remarks to get rid of kludgy code (though I have enough on my own, I should state...)<br /><br /><br />Regards<br />VolkerAnonymousnoreply@blogger.com