I am trying to get data off two devices that use SQL Anywhere 9 databases. They both currently run dbeng and I would like to use dbsrv instead so I can query the data from a central location.

I have read this article, but it's kind of lost on me because I'm not starting the process and I don't know what options are being used or assumed to be a specific default value.

I've been thinking about just renaming dbsrv9.exe to dbeng9.exe. It seems to work okay, but I don't want to do it in the live environment and have it break down the line, or find out that data hasn't been recorded properly in 6 months.

Is this an absolutely terrible idea? Is there another way around this? If it does seem like an okay idea, is there anything I can check to make sure that everything is working as expected?

I don't know why I didn't think of it sooner. Probably because deep down I know Martin is right... One thing I forgot to mention is that if I stop the dbeng service and start dbsrv, I am able to talk to the database as you would expect, but the software that started the service no longer functions.

I believe I misspoke earlier when I said service. I really meant process. There are two processes running at start-up, but from what I can tell, they aren't what I care about (dbisqlg and scjview). Under the Services viewer, I see 4 items related to my problem: Automation, Core, DataStore and ReportGenerator. I'm not sure I want to mess with these as they have dependencies on each other, and they don't seem editable.

No longer functions means no longer connected. Like if I am connected, via Db-visualizer and I restart dbeng or dbsrv, I need to reconnect if I go to pull data out of it again. I don't have a way to reconnect the proprietary software to the data store besides restarting it, and it won't start properly if I restart the process first. Basically it fails silently when it tries to do any look-up. That's why I've been looking for a solution that works with the start-up process.

As for the two devices, that was probably misleading as well. Two separate computers connected to data collection devices. They both run their own database server and aren't related, except for the fact they both use dbeng9.

From one perspective, your idea is no different than any other change proposed for a "live environment"... it must be tested.

From another perspective, renaming SQL Anywhere components has been a time-honored tradition for many embedded applications of SQL Anywhere (go ahead, hunt around in Quicken's installation, see if you can find any names you recognize)... so by renaming dbsrv9.exe you will be joining a large club. See Why "Invisible Database"?

Sadly, I do not know of any documents that talk about renaming techniques and the perils and pitfalls thereof... perhaps Mr. Kleisath can pitch in :)

More...

Personal experience indicates that switching back and forth between dbeng*.exe to dbsrv*.exe by simply editing three letters on the command line is an error-free process. In the course of a day I start engines dozens and sometimes hundreds of times, working on articles and blog posts and client assignments and application development, and switching between eng/srv has never been a cause for concern (except, on occasion, when the switch from srv to eng was the wrong thing to do from a limitations perspective). Database damage has never never never never never been caused by switching engines. That's five "nevers", the highest rating :)

While, as Breck says, some of our OEM partners do rename their SQL Anywhere executables, it does impose a higher level of care and support on those partners. As Martin points out, anytime there is an update, YOU have to take steps to ensure it is applied correctly, and then rename everything back again. Perhaps this isn't a problem in your environment, since the likelihood of any new updates for version 9 is about 0%. Engineering support for version 9 ended in January 2010 (http://www.sybase.com/detail?id=1061840)

If your primary concern is that the Personal Server and the Network Server treat your data with the same care and robustness, then you don't have to worry. As Breck points out, there is NEVER^5 a problem switching between the 2 engines.

The switch from a personal engine (dbengX.exe) to a network server (dbsrvX.exe) is not that complicated - the network server is simply more powerful, and some defaults have different values. Basically, you would just have to replace "dbeng9.exe" with "dbsrv9.exe" in the command line of your application's connection string. (And that's far more senseful than to rename the program file! - I clearly share Martin's point of view).

However, when you are going to switch from a database running locally (and that is possibly auto-started with the application) to a database running on a different machine (that is usually running permanently and commonly running as a service), there are a few more tasks to do:

RE: replace "dbeng9.exe" with "dbsrv9.exe" in the command line of your application's connection string.

I would prefer that option, but I've scoured around in the program files and start-up services of the computer running the the database and have been unsuccessful in finding the command that actually starts the process.

This leads me to believe that it is hard coded in one of the executable files, which is why I am being forced to come up with solutions as drastic as this.

We might be able to achieve this depending on how the application is setup to do the connection - hardcoded could be a problem but if connecting via ODBC or another interface that is pulling info from an editable source it would not be too difficult. Many applications rely on the engines autostart capability which likely explains why you are unable to find a reference to dbeng9.exe. You could take a look at the ODBC administrator to see if there is a DSN that is using the "Adaptive Server Anywhere 9.0" ODBC driver. If there is one, we can determine whether it is used by the application and modify it to connect to a server engine instead. Note: there are two ODBC administrators one for 32bit and one for 64 bit. You might find this a little easier in the registry. The 64 bit ODBC entries are found at:

If you find entries with the Data column value "Adaptive Server Anywhere 9.0", those are candidates for investigation. If we can locate a DSN that is used by the application, we can potentially modify it to connect to a network server rather than the personal server.

It is in general a terrible idea to rename a third party tool, you would have to rename the file each time you do an update. And non of your colleagues will ever guess, that the eng is in reality a srv process...

Just use Sybase Central, it provides a wizard to go through the steps of creating a database server. It is really easy.