August 24, 2009 at 6:07 pm
I've been running 64-bit sql server 2008 (Developer Edition)for about 6 months, and have noticed a few things that, well, just don't work. Since I've run across some, I'd like to know what all other issues are out there. So, anyone with an issue on 64-bit SQL, please respond. And if you know how to work around any of these issues, please let us all know!
Overall, SQL itself runs very good. But the issues that I've noticed all deal with external data access, and are:
1. Lack of 64-bit drivers for external data access (via Linked servers, or the OpenRowset/OpenDataSource/OpenQuery functions). This prevents access to text/csv/Excel files.
2. SSIS also can't work with Excel files, though it is working with csv files. (I guess that this means that I'm using the wrong provider for OpenRowset for the text/csv files...)
Yes, there is a 64-bit MSDASQL driver available. But, since it's a OLEDB/ODBC bridge, you have to have the underlying ODBC driver available in 64-bit.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
August 24, 2009 at 9:32 pm
I've been running several systems in production for several years now, and we have not had any problems. Of course, we do not have any issues with accessing other data like Excel or Access since we do not have those situations.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
August 24, 2009 at 9:50 pm
Wayne,
As far as linkedservers you will absolutely need 64-bit drivers, but using linked servers for text files or CSV or Excel files is just a bad idea regardless of 32 or 64-bit..
You CAN use excel and any of the other jet drivers in your SSIS packages, however you have to force execution with the 32-bit DTEXEC executable. You can't use the SSIS execute from SQLAgent, you have to use Operating System (cmdshell).
If you are using SQLCLR you need to be sure that any objects that your CLR code uses are available as both 32 and 64-bit. If your code doesn't depend on other assemblies then by default it should be ok.. Maybe I should say external assemblies, the MS provided ones should be good for both 32 or 64-bit.
If you have any extended stored procedures you may have a problem, but these are most common for monitoring tools..
CEWII
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply