cancel
Showing results for 
Search instead for 
Did you mean: 

Running multiple versions of Sybase SQL 12

0 Kudos

Hi all,

we are currently using SQL Anywhere V12.0.1.3537 and a customer is also running a Semantec AV product that is also using a V12.?.?.???? of SQL Anywhere.

Are there any issues with the Server running both versions at the same time?

Cheers

David

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

For the same Version number SQLA does not support the parallel installation of different builds. You could have an 16.0 and a 12.0.1 server on the same machine, but not a 12.0.1.3537 and a 12.0.1.3598.

Anyway both products should be able to work with a current EBF, be aware that a current EBF might need an upgrade of the DB file before the DB can be run in the current server.

You will get answers much faster on the SQL Anywhere Question and Answer forum http://sqlanywhere-forum.sybase.com/

jeff_albion
Employee
Employee
0 Kudos

For the same Version number SQLA does not support the parallel installation of different builds.

This is incorrect as stated - it is correct that we DO NOT support the parallel installation of full SQL Anywhere product installations of the same major build on the same machine. However, we DO support parallel deployments of the same SQL Anywhere major version on the same machine, which is what the original question asked (alternatively, a full version and a deployment - both are accepted).

It's simply a matter of separating the paths to the binaries and keeping environment variables straight. The easiest thing to do is to install SQL Anywhere 12 prior to the Symantec installation, so it should appear first in the system path, and no issues should be detected at runtime.

---

The only true conflict running the same major version between two deployments will actually be registering client components with Windows (which I can't speak to for the Symantec product as to how they do this).

For instance, the OLE DB driver has a static GUID it registers itself under, and so you cannot run multiple versions of the OLE DB provider on the same machine, due to the way it registers itself in the registry. This is the similar for the ODBC driver - however, you could edit the registry to get around this limitation if this was a concern for you, by creating separate ODBCINST.INI entries. For ADO.NET, there could be policy.* assemblies in the GAC that could silently map the assembly binding to a new build version.

Largely however, the client components are cross-version compatible, so small differences in builds if a different driver build version is accidentally picked up usually do not result in issues. Bugs in earlier client builds would obviously be the exception here - but this is why I didn't explicitly mention this issue in my earlier response due to this very small possibility and trying to keep some simplicity in my original reply.

---

Sidenote: We regularly run multiple builds of the same major version on the same machine in technical support to reproduce customer issues moving between builds. Again, if the paths and registry entries for your application are pointing in the correct binaries, there are absolutely no issues.

Jeff Albion

SAP Active Global Support

Answers (3)

Answers (3)

0 Kudos

Thanks to everyone who posted a reply.

(Yes I am now aware of SCN's moderation of all new topics [replies?] if the creator has less than 30 topics).

We install Sybase to a different location than normal so there will be two different component paths.

We always use the -n switch as part of the Server install routine and the Client install routine sets up the EngineName/DBN in the Registry/ODBC.

Also our Installs create an ODBC>ODBC.INI>%DSN%>'Driver' registry entry that points to our DBODBC12.dll path in full (C:\Sybase12\SQL Anywhere 12\bin32\dbodbc12.dll). I assume this should be fine for having different versions of the DBODBC.DLL client component.

Just to clarify using an example if we run a DBBACKUP/DBINIT/etc from CMD without pointing to our Sybase folder (ie: C:\Users\dsm\DBBACKUP -c "......) and it uses the OTHER Sybase V12 DBBACKUP would this cause a problem? Or will it depend on what build number of Sybase is being used?

Also does Sybase officially recommend that all Sybase utilities (DBBACKUP/DBINIT/etc) always include the full path (C:\Sybase12\SQL Anywhere 12\BIN32\dbbackup -c".....)?

Again thanks to everyone for their feedback.

David

jeff_albion
Employee
Employee
0 Kudos

Hi David,

Just to clarify using an example if we run a DBBACKUP/DBINIT/etc from CMD without pointing to our Sybase folder (ie: C:\Users\dsm\DBBACKUP -c "......) and it uses the OTHER Sybase V12 DBBACKUP would this cause a problem? Or will it depend on what build number of Sybase is being used?

In general, this should not cause a problem. Many of our utilities are really just executing SQL statements against the database server.

That said, specific behaviour differences/issues between builds may still be encountered. For example, if you are using specific forms of backup directory paths with trailing slashes, build 12.0.1.3814 may specifically change this behaviour: http://search.sybase.com/kbx/changerequests?bug_id=723135 - these are the types of issues that may appear in a mixed-version setting if the appropriate paths are not referenced.

Also does Sybase officially recommend that all Sybase utilities (DBBACKUP/DBINIT/etc) always include the full path (C:\Sybase12\SQL Anywhere 12\BIN32\dbbackup -c".....)?

Yes, as Windows will also pull the DLLs from the same execution folder first, which should help ensure DLL version matching:

     http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

Regards,

Jeff Albion

SAP Active Global Support

Former Member
0 Kudos

I have a similar situation in that I want to run to separate databases under the same build of sqlanywhere. However, when licensed we opted for the 10 user setup. what would I need to do in order to run a second database under this license. Would I need to "upgrade to the cpu license ?

JasonHinsperger
Advisor
Advisor
0 Kudos

You can run as many databases as you want on your server, regardless of the number of CPU/user licenses you have.

In your case, if you only have 10 user licenses, you are allowed 10 connections to any database on that server, not 10 connections to one database on that server.  For example, you could have 9 connections to Database1, and 1 connection to Database2.

If you need more than the 10 connections you already have, you can purchase more seats or purchase a CPU license.

--Jason HInsperger

Sr. Product Manager

SAP

reimer_pods
Participant
0 Kudos

David,

in addition to Jeff's answer there's one thing to be aware of: if there are different releases of the same product installed on one machine, look at SA specific path entries and environment variables. They may influence what happens, when you start programs from the command line.

EBF installations should run as expected if the Symantec SA version is installed as part of the AV product, not as a regular installation package like SA Studio.

Regards

Reimer

jeff_albion
Employee
Employee
0 Kudos

Hi David,

Are there any issues with the Server running both versions at the same time?

If you are careful about the database server and database client configuration, no, there should not be issues with this arrangement. Be aware of server hardware resourcing limits when you run multiple database servers on the same server.

Also be aware that whenever you have a database server starting up, it should be uniquely named (dbsrv12 -n server option), and every database you are connecting to is also uniquely named on that database server (-n database option). Then in your connection string for your application, be sure to specify the associated "SERVER=" and "DBN=" connection parameters with your database that you specified in the server configuration.

If you are seeing specific issues when running these servers consecutively, please reply back and we can try to help you out with your specific issue.

Regards,

Jeff Albion

SAP Active Global Support