Sql Anywhere 10 Odbc Driver Windows 7 Download
Gifford Brickley
I am trying to convert data from a client's database that was built using the ASA 8.0 engine. ASA 8 has been out of support since 2008. The software company that created this no longer supports it, so can't provide me with the drivers. I've scoured the web and can't find anything.
I managed to get the installation files for this old software called BailCredit built by a company called SentryLink. I found what I presume to be the ODBC driver in the installation files (dbodbc8.dll) and I've tried manually registering that (Windows Server 2008 R2) but didn't get anywhere. When I try to create a new datasource, the ODBC Data Source Administrator gives me an error.
I wasn't able to find this commercially available anywhere. I happened to be able to get my hands on the installation for the software package that was using SQLAnywhere 8. By installing this, it installed the necessary drivers (but only worked on 32-bit OS).
I have checked both the ODBCDriverSelector on the machine running the Designer and DSConnectionManager on the server, and the drivers are all correct for SQL Anywhere 12. I can also successfully connect to the database from the Windows Repository Manager - the only problem is with the Designer.
I have tried adding an ODBC entry in the System DSNs for the repo database, and again I can successfully test the connection - but this hasn't fixed my issue, and the Designer can connect (when it can connect) even if a DSN isn't defined.
I have a solution - in the CMC, set the repo to use DNS. You need to first create an appropriate entry in the /sap_bobj/enterprise_xi40/odbc.ini and then create an equivalent entry on your client ODBC settings.
In red hat linux i have installed IPS ( information platform services )along with bundled sqlanywhere database and Data services successfully. During installation of IPS, CMS and AUDIT database and DSN's are created successfully. Upto here there is no issues.
Do i need to do any ODBC configuration in linux level before doing at windows level.I tried creating DSN using DSConnectionManager.sh at linux side....after giving all details and click on test connection, it is working successfully, but when i close the DSN and open again the passowrd is missing.
sudo apt install msodbcsql18
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
Etc, etc.
Really wish MS, having offered SQL Server for Linux, could keep up at least with the main LTS's. 22.04 has been out now for 8 months and MS will no doubt have had industry pre-knowledge. People are using it for development and production so it's now really important.
Rgds
When will this issue be resolved. Come April there will be no more official security updated for ubunto 20.04. all our servers will be upgraded to ubunto 22.04 with ssl3. Microsoft ODBC drivers do not support openSSL 3 as of yet. This is a huge problem is any one looking into this?
We are currently exploring switching all our servers and clients data to PostgreSQL. That's approximately 300 clients data. The software is developed in house, so a switch from MS SQL will be a pain but it is do able. I know Microsoft doesn't care about this and never will, we are not big enough to matter to them. We are waiting till April first to see if there are any solutions from the linux community. It is the end of life for ubunto 20.04, as it will not be maintained any more. and all our servers will be upgraded to 22.04.
There are hacks to down grade Openssl 3 to V1 . but I don't see the logic in compromising one systems security for Microsoft.
If you are developing in Python and Django there you can import pymssql. This does not require any Microsoft drivers however it is no longer maintained and you do have to modify a bit of code to make it work. Microsof and Mac both need to just be honest and say "We have no interest in working with anyone else. If you don't like it leave" instead of pretending to support different OS half the time. There are so many Database options out there that support all OS platforms that there is no need to develop in Microsoft SQL server. As a developer I will always support platforms that are universal, It just makes my life easy.
They have one month to make a patch before we start switching all our clients over to postgress.
cheaper will be to use notepad
"cheaper" is just one parameter to take into consideration out of of tens of parameters, but we cannot know what best fit your needs, only you should know. Good luck with any decision to got.
You are totally current. It is a great database server which can fit most cases. My last response was not related to this specific solution but just noted about the reason you mentioned "cheaper". I just wanted to emphasize that cheaper is just one parameter when you select the solution.
As an example, consider an application that uses a SQL Anywhere database. A developer must consider the fact that other applications may also be using their own installations of SQL Anywhere on the same machine, without the end user knowing about it. As such, you have to consider how to prevent your SQL Anywhere components from being updated or replaced by another third-party application, outside of your control.
If another application that embeds SQL Anywhere is installed, it can potentially overwrite the ODBC driver your application installed with a different maintenance release or EBF build number, possibly incompatible with your application. The next time your application runs, the user could encounter problems that will be difficult to track down. Similarly, the installation of your program may overwrite an existing ODBC driver, potentially causing problems with other applications already installed on the machine. Worse, uninstalling another application may remove the ODBC driver that your application relies on, stopping your application before it can even start.
To prevent this, you can create your own custom driver name in the ODBC Registry on Windows, and make sure it always points to the SQL Anywhere ODBC driver that you install with your application. This way, you can ensure the location and specifics of the ODBC driver libraries that you want your application to use during normal operation, and you can ensure you will not affect the ODBC drivers of any other applications on the system if your application is updated or uninstalled.
The following is a walkthrough of how to create your own custom ODBC driver entry by setting specific values in the Registry by using the regedit utility. Once you understand how this works, you can use the windows API functions to open and write the specific keys you require to automate the process.
The Windows API provides methods for accessing and modifying the Registry to add the new ODBC driver as part of an application installation. The following function demonstrates how a new Registry key can be created and set for your ODBC driver programmatically.
By creating your own custom ODBC driver entry, you effectively can isolate your application database connectivity components from other applications running on the same system. This decreases the chance for deployment problems, and problems related to applying maintenance or other upgrades. In turn, this decreases the amount of installation and configuration support that will be required during deployment, and improves the overall end user experience with your application.
There is apparently no recent version available for version 13. We already have ODBC driver 17.10.4.1 and ODBC driver 18.2.2.1 installed, so we duly uninstalled ODBC driver 13.3.6430.49 from the server.
A "Microsoft ODBC driver 13 for SQL Server" warning popped up highlighting that the SQL Server Agent service was dependent on this driver version. And as expected, after uninstalling ODBC driver 13, the SQL Server Agent service refused to start.
We have only been able to obtain ODBC driver 13.0.811.168 from the Microsoft website, so now our driver is even more out of date! On a different server running the same build of SQL Server 2016, it lists ODBC Driver 13 as being version 14.0.1000.169, and this has not been flagged as a vulnerable version, but we cannot find anywhere to download this version from!
So the question is, how do we resolve this vulnerability without breaking the SQL Server Agent service? Why is the SQL Server Agent service on our machine still dependent on ODBC driver 13 when drivers 17 and 18 are available? Where can we obtain ODBC Driver 13 build 14.0.1000.169 from?
As per the above and attached, we already have ODBC driver 17.10.4.1 and ODBC driver 18.2.2.1 installed. We don't understand the dependency that the SQL Server Agent service has on the ODBC driver 13.
The redistributable installer for Microsoft ODBC Driver 18 for SQL Server installs the client components, which are required during run time to take advantage of newer SQL Server features (SSIS, R objects, etc).
This could be the reason the SQL server agent service is not starting if SSIS, R objects, and others components were installed, and the ODBC driver was removed. You may consider running a repair on the SQL server installation.
We recommend that customers who are running ODBC versions 11 and 13 as part of an application outside of a SQL Server installation update to ODBC versions 17 or above or OLE DB versions 18 or above, which provide protection against this vulnerability. ODBC and OLE DB driver installations that are part of a supported SQL Server installation will be updated via SQL Server cumulative updates or general distribution release updates.
What installer would have created these ODBC DLLs? We have a few severs where the SQL Server 2016 builds are exactly the same (13.0.6430.49), but on some of the servers the ODBC version 13 drivers are 13.0.811.168 (i.e. vulnerable) and on others they are 14.0.1000.169 (i.e. not vulnerable). So we feel less confident that a future CU will address this.
b1e95dc632