In all cases, this is the search order of the windows operating system: 1 The directory where the executable module for the current process is located. 2 The current directory. 3 The Windows system directory. The GetSystemDirectory function retrieves the path of this directory. 4 The Windows directory. The GetWindowsDirectory function retrieves the path of this directory. 5 The directories listed in the PATH environment variable.
The fork in the road is if it is a 32 bit executable, number 3 is going to be the SystemWOW64 subdirectory and if 64 bit, the System32 subdirectory. The RBase 9.5 64-bit database is still a 32 bit executable, so if your RBase EXE, regardless of whether it is a compiled EXE or the standard installed EXE, and the EXEs are within the scope of numbers 1-5, all should be well in Karen world. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Karen > Tellef > Sent: Wednesday, December 02, 2015 1:12 PM > To: [email protected] > Subject: [RBASE-L] - SConnect setup > > Just want to confirm that what I'm seeing is correct. I wanted to do a > DSN-less connection to another RBase 9.5 64-bit database. I normally > run with a -a parameter and keep all the DLLs in the RBase executable > directory. > > However, when I do that I get an error message about not finding the > RBG95_64.DLL file (and the _INS) in the c:\windows\system32 directory. > Creating a System DSN gave me the same message. Copying the 2 DLLs > into that directory didn't work, I needed to copy into the SysWOW64 > directory. Once they were in SysWOW64 then I could do a DSN-less > connection. I do have lots of notes about the whole system32/syswow64 > issue so I'm familiar with that topic, that's not my real question. > > My question is: is it IMPOSSIBLE to set up DSN-less or a System DSN > unless you have your DLLs in the windows subdirectory? If that is the > case, then from now on I would have to treat my -a > installations/updates like a "typical" installation, right? And I'm > guessing that if I was using the Compiler I could not use ODBC because > these DLLs wouldn't be present? > > We'd rather not pursue Oterro for this because we're just using a table > for read-only purposes, won't be updating the table or > inserting/deleting. > > Karen >
