Switching dbsrv and dbeng

[Former Member]

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?

[Breck_Carter]

IMO it is a clever idea, not one that I would have thought of.

But... clever ideas often suck, which is what you're concerned about 🙂

[Former Member]

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.

[Breck_Carter]

When you say "service", do you mean "Windows Service" as in those thingies listed in Control Panel - Administrative Tools - Services?

When you say "no longer functions", what is the exact symptom?

When you say "two devices", what exactly do you mean? PCs? Apple iPhones? Fedex handhelds? Medtronic pacemakers? Samsung smart TVs? Google Chromecasts? (ok, that's just silly, SQL Anywhere doesn't run on Chromecast... yet... does it? 🙂

I suggest you post a new question: "How do I fix [no longer functions]?"

[Former Member]

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.

[Breck_Carter · Accepted solution]

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 🙂

[Chris_Kleisath · Accepted solution]

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.

[Former Member · Accepted solution]

Awesome you guys, thanks. I'm still exploring other options, but it's good to know that if worse comes to worst I should be able to get away with it.

[VolkerBarth]

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:

• Starting the network server - I would recommend to do that "manually" first
• Connecting to the network server from a different machine - that will require to use TCP/IP as network protocol
• Adapting the connection strings used by your application (i.e. you may have to change the contents of an ODBC DSN or the like)

If that does work, I would finally setup the database server as a service:

• Running the database server outside the current session

But that is not that complex, either.

---

Note: The links are pointing to the 10.0.1 docs but they should apply to version 9, too. You would just have to replace dbsrv10.exe with dbsrv9.exe...

[Former Member]

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.

[chris_keating]

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:

HKEY_LOCAL_MACHINESOFTWAREODBCODBC.INIODBC Data Sources HKEY_CURRENT_USERSoftwareODBCODBC.INIODBC Data Sources

The 32 bit entries are found: HKEY_LOCAL_MACHINESOFTWAREWow6432NodeODBCODBC.INIODBC Data Sources

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.

[Former Member]

Awesome, I think that's it! Under System DNS it has an Adaptive Server Anywhere 9.0 driver with a start line dbeng9.exe -c 8m -gp 32768 -d -ge 95536 and the proper database file.

[MCMartin]

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.

[jack_schueler]

Re: I'm not starting the service and I don't know what options are being used or assumed to be a specific default value.

You might try the dbsvc tool to get that information.

Usage: dbsvc [options] -d <svc>                     delete a service
       dbsvc [options] -g <svc>                     get details of a service
       dbsvc [options] -l                           list all ASA services
       dbsvc [options] -u <svc>                     start service
       dbsvc [options] -x <svc>                     stop service
       dbsvc [creation options] -w <svc> <Details>  create service

[Former Member]

I don't quite get what you mean. Is this tool supposed to show you what options were given when a specific process was started?

I tried dbsvc -l and it didn't return anything, even though I know that there is one running.

[jack_schueler]

You said that the server was installed and running as a service. The dbsvc tool will show you which ASA services you have installed as a service on your PC.

You said "off two devices that use SQL Anywhere 9 databases". I assume that you are running dbsvc on those devices.