Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.

We have a customer that is reporting a crash in dbeng12. One possibility is that SA12 has been incorrectly installed as our application does need SA12 to be installed as a 32-bit application and this is a 64-bit Windows 7 workstation.

How can I inquiry/search if the SQL Anywhere 12 client was installed using the 32 or the 64 bit option?

alt text

asked 23 Aug '13, 12:29

Derli%20Marcochi's gravatar image

Derli Marcochi
accept rate: 33%

edited 04 Sep '13, 19:44

The issue has not been recreated after EBF 3942 was applied in the workstation that reported the intermittent dbeng12 crashes. No other workstation/server has reported any crashes.

permanent link

answered 04 Sep '13, 19:40

Derli%20Marcochi's gravatar image

Derli Marcochi
accept rate: 33%

There seems to be some confusion here. The bitness of the server and the bitness of the application are for the most part independent of each other. If your application needs the 32-bit client to be installed, that is fine, but the crash report above is obviously for the server. Why then are you concentrating on the application? Regardless, the crash report above definitely indicates that you are using the 32-bit server (you can tell from EXEC_ARCH=x86 and the fact that the EXEC_PATH contains bin32). But again, if the crash is in the server, then why does it matter what bitness the application is, unless of course, your "application" is really a dll that is loaded by the server (as in the case of an external stored procedure call).

permanent link

answered 23 Aug '13, 14:34

Karim%20Khamis's gravatar image

Karim Khamis
accept rate: 40%

Thanks Karim. This issue is being reported by only one user (so far) that's why my assumption it seems to be related with the SA12 client installed.

Is there an utility or a db_property we could try to find out if the SA12 client was installed as 32 or 64 bit application?

(23 Aug '13, 14:47) Derli Marcochi
Replies hidden

It would be a stretch to believe that the client bitness would trigger a database server crash. That said, if your application is 32 bit, the client would also need to be 32 bit. A 32 bit application will not be able to connect using a 64 client - nor could a 64 bit application connect using a 32 bit client.

What connectivity technology are you using i.e, ODBC, JDBC, .NET, other?

(23 Aug '13, 16:27) Chris Keating

Yes, our application uses ODBC and does require the client to be 32-bit.

(23 Aug '13, 16:54) Derli Marcochi

Is there something for Windows similar to the dbversion utility for Unix?.

(26 Aug '13, 16:27) Derli Marcochi
Replies hidden

Right-clicking on the file in Windows Explorer, and going to the Properties -> Details -> Version section will show you the same information in Windows. sigcheck is a popular command-line utility to accomplish the same task.

(27 Aug '13, 07:19) Jeff Albion

Are you asking for the server or the client.

The server you can see by looking at the server executable itself, the server console log, or even just a SQL query:

SELECT PROPERTY('ProcessorArchitecture');

For the client, usually the application will be compiled and shipped with the associated client libraries. (Although this can vary somewhat with Java or .NET applications.)

For the actual issue (dbeng12 crashing) however, you may want to look at the server console log, or Windows event logs to see if any issues are reported.

permanent link

answered 23 Aug '13, 14:10

Tyson%20Lewis's gravatar image

Tyson Lewis
accept rate: 22%

Comment Text Removed

I need a way to check the bitness of the client not the server.

Note: I added the snag of the crash report

(23 Aug '13, 14:23) Derli Marcochi
Replies hidden

We unfortunately can't diagnose the server crash issue from just the screenshot information - we also need the mini-dump file minimally, and possibly require you to collect a full dump file if we haven't seen the crash issue previously.

You can try downloading the latest EBF patch to see if this resolves the crash issue. If not, you should open a technical support case so we can investigate further.

(27 Aug '13, 07:25) Jeff Albion

Just checked with customer that the crash is happening in one workstation only. No crashes reported in the server. They re-installed SA12.0.1.3873 in the workstation and after 4h or so a new crash was reported. Suggested applying EBF # 3942 and to save the dump/crash log if/when a new crash happens.

(27 Aug '13, 13:59) Derli Marcochi
Replies hidden

As Jeff mentioned, to diagnose the crash from the dump file, we'd need a technical support case to be opened.

I am curious however, since this is the workstation, and the crash is clearly occurring in the dbeng12 executable, this is a server crash. Is this workstation also the server for the database, or is the database hosted on a shared drive/nas/etc. and auto-started?

(27 Aug '13, 17:35) Tyson Lewis

The workstations do connect to running and local databases but AFAIK there is no db services running in the workstation itself.

(27 Aug '13, 17:49) Derli Marcochi

I think the answer to "Is this workstation also the server for the database" is "yes, it must be, because dbeng12 doesn't support network connections so the application and the engine have to be on the same box regardless of where the database file is located".

(27 Aug '13, 17:52) Breck Carter
showing 3 of 6 show all flat view
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: 23 Aug '13, 12:29

question was seen: 2,694 times

last updated: 04 Sep '13, 19:44