I have a multi-database setup that I need to work with and both have their own bcp versions that do not act the same way. Plus both are in my %PATH% and the Sybase one is listed before the MS SQL exe so calling "bcp" from the command line always hits the Sybase exe.
First, the versions are "different":
Sybase BCP:
Sybase CTBCP Utility/15.0/P-EBF17890 ESD #24/PC Intel/BUILD1500-123/OPT/Thu May 13 02:45:43 2010
(for Adaptive Server Enterprise/15.7/EBF 23008 SMP SP130 /P/RS6000/AIX 6.1/ase157sp13x/3819/64-bit/FBO/Sat Aug 23 02:49:06 2014)
MS SQL BCP:
Version: 11.0.2100.60
(queries hitting SQL 2008 R2 and 2012 SP3 dbs)
They definitely do not handle output to a file the same way and the docs for each show that. Everything I read on bcp says that bcp should work the same between Sybase and MS SQL but I have to call the full MS SQL bcp.exe path for a queryout call to MS SQL because the Sybase bcp does not support the queryout the same way.
My process uses a batch script to call multiple queries that hit the Sybase DBS and then MS SQL databases to output data to a staging db, will I always have to differentiate between the Sybase and MS SQL bcp's or can I use just one without issue? If so, which one is the "right" one to use (not trying to spark a debate here on which is better). Also, I see nothing showing that the version numbers have any relation what so ever so knowing which is the "latest" and using that one is proving difficult.
Keep in mind that MS SQL Server was identical to Sybase ASE back in 1994 (the called Sybase SQL Server), but after that, they slowly started to move apart. So the concept of BCP is still there and similar, but the details are different.
For one thing, do not expect to be able to interchange client tools for these databases: Microsoft has made changes to the TDS protocol that makes it impossible to connect a client to the other vendor's databases.
If you've got a clash between to two executables with the same name, common solutions include (i) explicitly specifying the executable's pathname (ii) setting the right environment variables before calling one or the other executable (iii) renaming one of the executables. YMMV.
Related
I would like to migrate a instance of SQL Server/11.0.3.2 to Sybase 11.9.2 (i want use SSMA after that). There is no documentation on this subject on the web because it's too old (1997).
I only want migrate 3 databases of my instance. I try to dump a db to Sybase 12.5.4, not work, ddlgen not work on 11.0.3.2. With the system table, i can recreate the SQL script for table, view, procedure... and then i bcp the data. But i think it's not a good way, it's too long and not safe...
An other solution: upgrade the server to 11.9.2 (or more), but as i say, i only want migrate 3 databases.
If sombody have an other way to do that, it's will be a great help.
Thank in advance.
You should be able to take a database dump from 11.0.3 and load it into a later ASE version. It is not formally supported, but I have done this successfully for ASE 12.5.
I'm being demanded to develop a new software that must be built over SharePoint and use Microsft SQL Server 2012.
I have a DB in Postgres, and some of its tables will be used in this new project, so I must import these tables, everyday. I'd like to use WebService to do it, but they want it to be done DB-to-DB directly.
Postgres-to-Postgres is already done and it "works", but importing to Microsoft is being troublesome.
Does anybody know some MSSQL tool that can connect to Postgres and do the import?
Typically for this sort of situation (assuming that it'll be a process that's repeated on a regular basis) you'd use SSIS (comes with most versions of MS SQL Server). Have a look at the first several hits on this Google search, especially the first one.
Another option is to connect to the Postgres database directly from your application via ODBC, and eliminate the redundant copy of the data - and get real-time updates instead of having to wait for the next execution of the SSIS job.
We ported a database server from SQLServer 2005 to SQLServer 2008 (SP1). The new server has more Processors (4 Quadcore versus 1 Quadcore ) and more memory (4GB versus 64GB).
Processors are 2.1Ghz(new) versus 2.0Ghz(old).
The new OS is Windows Server 2008 and the old is Windows Server 2003.
The databases were transfered via backup/restore and run in native SQL Server 2008 mode (not in SQLServer 2005 compatability mode ).
Some queries on the new server run slower than before. These queries use indexed views. The queryplan looks the same on both systems.
Most of the queries perform equal.
My task is now to decide if we have a problem with our SQLServer installation, if the we have a problem with the database or if this is an expexted result.
I first want to compare performance of both
Sytems
SQLServer installations.
Is there an easy way to do this?
Has anybody had comparabele results on new SQLServer installations?
Before you check your hardware/OS, make sure you:
update statistics
rebuild all indexes
and then run your tests again. Also, are the editions of SQL Server identical? There are differences in how you have to write queries against indexed views based on the edition (Standard vs. Enterprise) of SQL Server.
Also, confirm that your indexed views are still indexed properly by selecting 1 row from them and observing the query plan. You should see only one table in the resulting plan.
The easiest way to collect performance of both systems is to run a PAL, and collect the approriate data.
PAL has extra counter sets for SQL Server. It will collect and analyse the data, and let you know where you have an issue.
PAL can be found here
http://www.codeplex.com/PAL
Also an important issu is to location of the filegroups. How is the underlying storrage system defined? It usually has a huge impact on the SQL Server. (You should talk about spindels here, and not raw size...) Make sure your database files are not sharing the resources with anyone else
I have to move an entire database from a SQL Server 2008 machine to a SQL Server 2000 machine.
I created a backup using Management Studio 2008, copied it to the hard drive of the 2000 box, and from withing Management Studio 2008, I choose Restore Database to the 2000 box.
I get an error message stating, "The media family on device ... is incorrectly formed. SQL Server cannot restore this media family".
If I use Enterprise Manager 2000 I get the same error.
Is there a way to move a whole database from the newer SQL server to the older?
The only thing I can think of is to recreate the whole structure and then copy data from a live database. So, create scripts that will create the tables, views, and sp's, and then create scripts to copy the data from the existing database.
As others already said there is no default way to do this. It’s just not supported. Here are more extensive details on how to do this properly and avoid any migration issues.
You need to generate scripts for structure and data and then execute these on SQL 2000 (like others already said) but there are couple things to take into account.
Generate scripts in SSMS
Make sure to check option for scripting data for SQL 2000 to avoid issues when trying to create something like geography type column on SQL 2000.
Make sure to review execution order of scripts to avoid dependency based errors
This is a great option for small to medium size databases and requires some knowledge of SQL Server (dependencies, differences between versions and such)
Third party tools
Idea is to use third party database comparison tools such as ApexSQL Diff or Data Diff
Good side is that these will take care of script execution and differences between versions
Not so good is the fact that you’ll need to pay for these after trial ends
I’ve used these two tools successfully but you can’t go wrong with any other tool on the market. Here is a list of other tools in this category.
you can't move backups from a newer version to an older, in that case you can script your database, execute it in the 2000 box, then you can use the standard data transfer to transfer any data you want
Provided you have a network connection between the machines use SSIS. Much easier and a lot less messing around.
You can use Script Generator for your database and then select in the properties form : General-> Script for server version : SQL Server 2000.
The script generator will show you things which not compatible with your server version.
I've heard you can only do it by generating the SQL statement dump from the DB administrator tool and re-running those queries on the target older database.
You can generate a script that will recreate all the objects and transfer all the data...as long as everything in the db is valid in SQL 2000. So no ROW_NUMBER(), no PARTITION, no CTEs, no datetime2, hierarchy or several other field types, no EXECUTE AS, and lots of other goodness. Basically, there's a pretty good chance it's not possible unless your db is pretty basic.
We got a similar situation. A very low-tech but handy solution is:
backup and truncate the tables in SQL 2000.
create a LINKED server in SQL 2008, pointing to SQL 2000
run a select query at sysobjects to generate a query script for insert into LINKED SERVER.table select * from table
execute query script.
I have a SQL Server 2005 machine with a JDE DB2 set up as a linked server.
For some reason the performance of any queries from this box to the db2 box are horrible.
For example. The following takes 7 mins to run from Management Studio
SELECT *
FROM F42119
WHERE SDUPMJ >= 107256
Whereas it takes seconds to run in iSeries Navigator
Any thoughts? I'm assuming some config issue.
In certain searches SQL Server will decide to pull the entire table down to itself and sort and search the data within SQL Server instead of sending the query to the remote server. This is usually a problem with collation settings.
Make sure the provider has the following options set:
Data Access,
Collation Compatible,
Use Remote Collation
Then create a new Linked Server using the provider and select the following provider options
Dynamic Parameters,
Nested Queries,
Allow In Process
After setting the options change the query slightly to get a new query plan.
It might be a memory issue on your SQL Server machine. I recently learned that linked server queries use memory allocation by the OS. Whereas native SQL Server queries use memory pre-allocated by SQL Server. If your SQL Server machine is configured to use 90% or more of the server's memory, I would scale that back a bit. Maybe 60% is the right place to be.
Another thing to check is the SQL Server processor priority. Make sure "Boost SQL Server priority" is not enabled.
I assume you are going through ODBC for access. Remember that you are not writing native db2 queries here, but instead ODBC sql queries. If you only need read-only data, you may want to try configuring your ODBC datasource to read-only mode (if that is an option).
In a project with DB2 integration, I replaced every query via direct select or view by stored procedures calling the OPENQUERY function.
My interpretation is that SqlServer fetches the whole table before applying the WHERE conditions, whereas OPENQUERY passes the SQL statement directly to the db driver.
Anyway, performance was acceptable after the modifications.
My first thought would go to the drivers. Years ago I had to link DB2 to SQL Server 2000 and it was extremely difficult to find the correct combination of drivers and setup parameters that would work...
So maybe I'm biased because of that, but I would try upgrading or downgrading the driver or changing the setup so that the DB2 driver can run INPROC (if it's not already doing so).
I've had several issues with DB2 as a linked a server. I do not know if it will address your problems, but here is what fixed mine:
1) Enabled lazy close support and pre-fetch during EXECUTE in the ODBC settings
2) Add "FOR FETCH ONLY" on all selects
3) Query using the SELECT * FROM OPENROWSET(LinkedServerName, 'SQL Command') method