I am still having this problem with SP2 applied. Actually, on the test machine I removed everything and then installed using the full installer. It does not save the password when running as an application, nor when running as a service. Tested with 11.7.2 9610 (64-bit). A search of the entire C: drive for the cache.ini did not turn up any files.
Unfortunately, I can now reproduce this.
Both for the service and for the user.
I will log a defect.
I've created defect SQLB-2106 for this issue. Development is looking at this now.
Good to know I was not hallucinating the whole thing.
We are having a similar problem on our VM and 11.7 SP2 and I was wondering if you were able to get yours to work?
Please let me know when you get a chance.
No, I was never able to get it to work. I expect it will be fixed in SP3. My temporary work-around has been to install the SQLBase Command Center on the same machine and put a link to it in my Startup folder on the start menu. Our SQLBase Server was added to the Workspace node in the Command Center, which makes it do a server connection, which causes the databases to show up. You only have to remember to log into the Windows server right away if the machine is rebooted. It is not ideal because it ties the startup to a specific person logging into the Windows server. As I am still in testing mode for 11.7.2, that is not a huge problem.
Back with 11.0.x which did not have the save password feature I used to use a Windows service I wrote that would not require logging in. It would get triggered when the SQLBase Server program or service was started. Unfortunately for some reason I could not get it to work with 11.7.x. I have a memory Mike might have done something similar which might still work with 11.7.x.
Hope that helps,
I wrote an application that just takes the servername and server security password as parameters and just connects to the database. That seems to work fine with SP2 (at least with 32-bit). Andy seems to have a problem even with this application when using a VM machine.
Hmmmmm. Andy, is your VM a 32-bit or 64-bit machine? This defect is specific for a 64-bit machine.
Our VM is a 64-bit machine.
The fix for the 64-bit not saving still hasn't been resolved. I'm pushing for a SP3 fix for it. I won't let it get released without this fix.
AJ was having a problem with not being able to set this from SQLTalk or my application because he had a 'password=xxxxxx' statement in his server sql.ini file with a password of the *server security password*, and when he did a 'set server' it then only did a set of the 'administration password'. Once we changed this to 'password=*' the databases then came online with a set server statement.
So, Cliff, an alternative is to have a little bat file that fires up SQLTalk in bat mode which does a 'set server server/serversecuritypassword;' or you can have my little program that you can run that does the same thing; it just connect to the server with the password and then exits. Let me know if you want it.
Unless I am mistaken, doing a batch file leaves the password exposes in clear text, so I won't go that route.
How does your program store the password? Does it run as a service so someone does not need to log in? Does it work if the server service fails and restarts?
I understand the SQLTalk BAT option not being for you.
The application is written to accept two strings in the execution statement; servername and serversecuritypassword
So: setserverpassword.exe server1 serverpw
However, this is an *extremely simple* application (written in TD) and could be easily changed or written using a different front end. The servername and password could be hardcoded into the EXE or the app could be changed to pick this up from a registry entry, ini file, etc.
I'm not sure what system processing is available when a service is restarted, but I would envision this being run right after the service starts back up. I'm not sure how to get that done, though.
My process was designed to do more or less as you indicate. It stored the password in the Windows password manager so it was secure and only could be read when using a certain account. It was triggered by the starting of the SQLBase Server. I used an external DLL configured in the sql.ini to make that happen. I don't know why it no longer seems to want to work, even when I converted it to run as 64-bit.
Be that as it may, I had figured I would check with you about your program to find out if it would fit our requirements/needs. An potentially easy temporary solution. As it does not fit our requirements; and since my work-around with the SQLBase Command Center sort of works; and since you state that with SP3 the problem will be solved; I am thinking not to spend time on trying to revive my old process or modify and adapt yours.
As always, Thanks Mike!
Who is online
Users browsing this forum: [Ccbot] and 0 guests