The forum will be down for maintenance over the weekend of August 18-20, 2017. The forum will be shut down on the evening (EDT) of Friday, August 18. Downtime is unknown but may be up to two days. The forum will be restarted as soon as maintenance is complete.

(Yes, this is a rhetorical question... - Nevertheless, I'm gonna ask it here in an attempt to not forget about this seeming trivia.)

By embedded, I mean an application with a local database, and ENG is the classical connection parameter to specify the local database engine - whereas v12 prefers the SERVER parameter over the now deprecated ENG...

asked 03 Feb '12, 18:08

Volker%20Barth's gravatar image

Volker Barth
accept rate: 33%

edited 05 Feb '12, 13:01

Yes, you should specify this always - that is for each and every connection of your application - otherwise you might end up like me:

The story behind this question: We have used a SQL Remote setup for more than a decade as part of an application set. In the first time, we have called DBRemote.exe directly, but later switched to use the DBTools API to call the DBRemoteSQL() function, so the progress messages can be shown within the application itself. All fine - unless users restore old databases from backups and break replication that way....

In very rare cases, however, the replication didn't work, since DBRemoteSQL() couldn't start the database. This was unepxected, as the database is already loaded when the API is called. Very strange, happened only two or three times in all those years but was reproducable then. Interestingly enough, calling DBRemote.exe once with the same parameters has worked in those cases, and usually, then the problem went away. - I have considered this one of those cases where you decide "You don't need to understand each mystery" and go on.

Yesterday, the same happened again on a customer machine, reproducable with remote control, and the explicit DBRemote.exe call worked. But this time the API call still wouldn't work, and - let's say based on some undeserved intuition - I checked the running processes and found a running dbsrv9.exe. That led to the solution: I stopped that database engine, and then our replication worked again as usual. (BTW: It was a Lexware product that has installed the dbsrv9.exe).

So I checked back the code and found out that when starting our application, we surely do use both ENG and DBN parameters (from an ODBC DSN), however, when preparing the API call, only the DBN (and credentials) was specified, whereas the ENG parameter was missing.

Apparently, that made DBRemoteSQL() try to start the database file on the default local database engine, and in the (very rare) case there was another dbengX/dbsrvX running locally (and started before our own engine), it would try to load the (already loaded) database on the wrong engine. - As our users seem to have rarely used products with a permanently running "foreign" SQL Anywhere database engines, that background was difficult to track...

Personal resume: Another lesson learnt - though I would have bet that exactly that lesson was already learnt:).

Just to add:

  • The fix was an easy one, didn't need any code change as the missing connection parameter could simply be added in the configuration file.
  • And it's all documented very well in the docs - particularly here. - But that wasn't the point here: I was just too sure that I would not happen to stumble over such a well-known pitfall:)
permanent link

answered 03 Feb '12, 18:41

Volker%20Barth's gravatar image

Volker Barth
accept rate: 33%

edited 05 Feb '12, 13:14

Volker, you are a tour de force. You ask the questions, you answer them, and people are clicking-away thumbs-up for both. :)

(04 Feb '12, 10:18) dejstone
Replies hidden

Hmm, it feels somewhat embarrassing to get so many votes for having fixed one's own bugs - but if you like to learn from my mistakes, I'm gonna feel free to tell about them:)

(05 Feb '12, 13:17) Volker Barth
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 03 Feb '12, 18:08

question was seen: 1,074 times

last updated: 05 Feb '12, 13:17