We are currently running SQL Anywhere 12.0.1, EBF 3895 in our application. We have been running it 32-bit only. We now want to run it 64-bit on 64-bit machines.

I reinstalled SQL Anywhere on my machine & installed it for 32 & 64 bit environments. When I look in the C:\Program Files\SQL Anywhere 12\Assembly\V4 folder, however, there are only the same managed DLLs we have in our application now.

Our installer currently installs the 32-bit version of SA. I don't know what the plan is, but if we install the 64-bit SA executables, do we need 64-bit managed DLLs to go along with that? If so, are there any changes we need to make to our projects to get them to work with the 64-bit SA install? Are there any changes we have to make in app.config?

If we don't need 64-bit managed DLLs, how do we get our program to work with the 64-bit install? Again, are there any changes we have to make in app.config?

asked 22 Aug '14, 11:54

TonyV's gravatar image

accept rate: 75%

These managed files can be used for both bitness. By default, .NET managed code is bitness agnostic meaning that it will run aither as x86, x64 or Itanium depending on the chip and the operating system bitness. Note that SQL Anywhere currently only supports x86 and x64.

This behaviour is controlled by the "Any CPU" Platform option in the configuration manager. You can change this to x32 to force a 32-bit only build, x64 to force a 64-bit only build, or Itanium to force an Itanium only build. In generally, you would leave this at its default value unless you had unmanaged code that was bitness/chipset specific.

permanent link

answered 22 Aug '14, 13:35

Chris%20Keating's gravatar image

Chris Keating
accept rate: 27%

Thanks, that's what I thought, given that there was only one set of DLLs.

I seem to recall a problem I had some time ago where I had build my program with Any CPU and a DLL that was embedded in one of the SA DLLs had the wrong bitness. The managed code was running as 64-bit, but the server running was 32-bit only. What I think you're saying is the reason this happened is because the managed code's bitness didn't match the bitness of the server. If everything is the same bitness, there's no problem. Correct?

(22 Aug '14, 14:07) TonyV

I recall an issue with unpacking the unmanaged DLL but I cannot recall the details - it has been fixed for some time.

There should be no problems provided that the managed and unmanaged code are the same bitness,

(22 Aug '14, 14:54) Chris Keating
Replies hidden

In addition to what Chris said...

Some of the files listed below appear in the V4 folder, and others appear in both the bin32 and bin64 folders.

.NET client deployment

SQL Anywhere provider for .NET Framework 4.0 The SQL Anywhere installation places the Windows assemblies for the .NET Framework version 4.0 in the Assembly\V4 subdirectory of your SQL Anywhere installation directory. The other files are placed in the operating-system binaries directory of your SQL Anywhere installation directory (for example, bin32 or bin64). The following files are required.








(22 Aug '14, 15:46) Breck Carter

Now that I've got everything building & running properly, I've been able to confirm that building & running the application as 32-bit connects to a 32-bit or 64-bit server without error, and the same is true if you build & run it as 64-bit. We didn't have to make any code or configuration changes. We're happy! ;)

(22 Aug '14, 16:59) TonyV
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](http://url.com/ "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: 22 Aug '14, 11:54

question was seen: 537 times

last updated: 22 Aug '14, 16:59