Embracing new technologies have a implied warning label, especially when dealing with specialty software markets, like library software. Take as in my case, a Dynix library catalogue on Microsoft SQL 2000, Windows XP Professional x64, Then add to that one fat windows based library software client, SirsiDynix‘s Horizon client version 7. Will they work together?
Short answer: No, not "Out of the Box".
Long answer: Yes, but only if you know about the "workaround". And it comes with cavaents.
Embracing new technologies have a implied warning label, especially when dealing with specialty software markets, like library software. Take as in my case, a Dynix library catalogue on Microsoft SQL 2000, Windows XP Professional x64, Then add to that one fat windows based library software client, SirsiDynix‘s Horizon client version 7. Will they work together?
Short answer: No, not "Out of the Box".
Long answer: Yes, but only if you know about the "workaround". And it comes with cavaents.
If you install everything by the book: the SQL Server 2000 client tools, the java runtime environment, and the Horizon client. Reboot. Apply SP4 for SQL Server 2000 on your local installation (really just to patch the client tools, in attempt to be complete). Modify the shortcut on your desktop to include the "-@m" to tell the Horizon client to connect to a Microsoft database, and don’t forget to add the alias to your library database in the client tools. What happens when you double click the Horizon client shortcut?
A little error message pops up and says "No list of servers is available!"
What to do? This blog gives some hints as to why it isn’t working:
Note: SQL Server 32-bit applications, including SQL server client tools, are still not supported on WOW64 for IA64. Also, currently 32-bit Reporting Services is not supported to run on WOW64 on IA64 and x64 platforms running Windows Server 2003 x64 Edition.
In a nutshell, I translate this in from the Horizon client point of view that "I can’t see/read the alias created via the client tools!" I suspect that it is something similar to that anyway – and please correct any part this article in the comments below.
How to workaround this problem? Well, you start by un-installing Microsoft SQL Server 2000 from your workstation. Then download SQL Server Express edition from Microsoft. Run the installer, follow the prompts past the System Configuration Check, until you get to feature selection. I suggest X’ing the database services, and add the Connectivity Components. After all, I am after is a connection to the Horizon database. If you have other goals in mind (say web development), then of course choose appropriately. Next into the Error and Usage Reporting, picking what you would like to do (I chose not to send errors). Next into the Ready to Install, click Install. Wait for that to settle up, and end off by following the installer prompts and clicking the finish button.
Find off the Windows Start button SQL Server 2005 > Configuration Tools > SQL Server Configuration Manager and click on it. Double click in the Configuration Manager Native Client Configuration, and Client Protocols. I disabled every protocol with the exception of tcp/ip, because that is all that is needed to connect to Horizon Database. Double click Aliases, right click on an empty space in the right pane; pick New Alias, and create a server alias much the same as you would for SQL Server 2000 Client Tools. Click Apply, OK and close the Manager.
Viola! Double click the Horizon client shortcut, and you should be present with the normal login prompt of the Horizon login prompts.
It does some with caveants. I spoke with Support and the company stressed that a setup like this is definately not supported. Essentially that means, that if a support incident crops (say database corruption) and gets traced to the Horizon Client on 64bit Windows, you would likely have to pay the support costs to bring the catalogue back to normal.
The client tools for SQL Express are really designed to connect to a SQL 2005 capable server, not 2000. Therefore, there is an off chance that the SQL Server 2000 might not interpret the connection commands correctly. We haven’t fully tested this setup ourselves, so there no way to tell at this point what the implications total up to.
I am of the opinion, that some light catalogue only searching would be ok to do. Heavier stuff, like circulation, cataloguing, or administration, I would not recommend.
But what does the community think?
Recent Comments