I have a SQL Server 2005 instance, into which I am trying to import data from a SQL Server 2008 instance using an SQL Query. I am using the 2008 management studio, and the import/export data wizard.
If I run the select query separately in the management studio, it correctly returns the ~88k rows that are required. The query returns the data with the exact column names and types required by the destination table.
When I run the import wizard, the sql query parses correctly, and the 'Preview' button correctly shows the data. There are no errors or warnings in the conversion section. The task is set to fail if there are any failures in conversion.
When I run the task, no errors are displayed. However, it shows '0 rows transferred' and no data is imported.
Any ideas why?
edit: tried importing to a table created on import in a fresh new db, and still the same result. I'm wondering if the direction of movement from 2008 to 2005 is important (i.e. 2005 can't handle a 2008 feed correctly).
If you have "USE [database]" as part of your query, then this single line is all that gets executed during the import/export.
The solution is to remove the "USE" statement as part of your query.
I've never had much luck with the SQL server management studio's import features under 2005/8.
Lately, I do one of two things.
Either I just use it to import the data into a brand new table on the target server (not even a table of the exact same structure) then run an insert statement to transfer from that newly created table into the destination.
Or I use a tool like Visual Studio for Database Professional (or Redgate) to transfer the data.
I've used the import successfully. Chris has a good suggestion (this is the process I typically follow) though on using a middle table or file. That gives you the ability to do some simple transforms using queries rather than SQL's transform tool. It also gives you a buffer in case things go wrong or you need to isolate issues.
I had a similar problem using the import utility for 2008. We had Oracle native SQL that ran fine in TOAD but imported with 0 rows using the SQL Server import utility. The culprit ended up being related to Oracle's date format. The SQL referred to dates such as '03-JUN-2013'. Once I changed them to use the TO_DATE function such as TO_DATE('06/03/2013','MM/DD/YYYY') we had a successfully execution and import.
Related
I need to run some analysis on my queries (specifically finding all the tables which a ssis calls).
Right now I'm opening up every single ssis package, every single step in it and copy and pasting manually the tables from it.
As you can imagine it's very time consuming and mind-numbing.
Is there a way to do export all the queries automatically ?
btw i'm using sql server 2012
Retrieve Queries is not a simple process, you can work in two ways to achieve it:
Analyzing the .dtsx package XML content using Regular Expression
SSIS packages (.dtsx) are XML files, you can read these file as text file and use Regular Expressions to retrieve tables (as example you may search all sentences that starts with SELECT, UPDATE, DELETE, DROP, ... keywords)
There are some questions asking to retrieve some information from .dtsx files that you can refer to to get some ideas:
Reverse engineering SSIS package using C#
Automate Version number Retrieval from .Dtsx files
Using SQL Profiler
You can create and run an SQL Profiler trace on the SQL Server instance and filter on all T-SQL commands executed while executing the ssis package. Some examples can be found in the following posts:
How to capture queries, tables and fields using the SQL Server Profiler
How to monitor just t-sql commands in SQL Profiler?
SSIS OLE DB Source Editor Data Access Mode: “SQL command” vs “Table or view”
Is there a way in SQL profiler to filter by INSERT statements?
Filter Events in a Trace (SQL Server Profiler)
Also you can use Extended Events (has more options than profiler) to monitor the server and collect SQL commands:
Getting Started with Extended Events in SQL Server 2012
Capturing queries run by user on SQL Server using extended events
You could create a schema for this specific project and then have all the SQL stored within views on that schema... Will help keep things tidy and help with issues like this.
I want to be able to run a query every day at the same time and have it automatically save to a location with a specific file name.
Is this possible? Without SSIS or cmdlet or PowerShell, I want to do it all within the query I'm running,
I understand INTO outfile is a mysql syntax, is there an alternative for SQL Server?
i understand INTO outfile is a mysql syntax , is there an alternative for ms sql?
I'm assuming you're saying you don't want to use any external tools, including tools that ship with SQL Server itself. You want something you can run as an SQL query to create the file and without creating an SSIS package (even a package from the Import/Export Wizard).
No. There are no T-SQL statements supported by MS SQL Server which themselves cause the database engine to write the output directly to a file.
There is no native MS SQL Server equivalent to MySQL's INTO <outfile>, PostgreSQL's COPY (<query>) TO <outfile>, or Oracle's spool command. As far as MS SQL Server is concerned, writing data to an external file is the entirely responsibility of whatever database client you're using.
The closest you can get would be a CLR function or stored procedure similar to the apparently abandoned https://archive.codeplex.com/?p=sqlclrexport#
I suppose you could also use xp_cmdshell with bcp.exe, but that's kind of cheating around your requirements.
I've created the structure of my database first in PhpMyAdmin and exported it to a .sql file.
Now I'm looking everywhere in SQL Server Management Studio where I can import/add the data in a new database.
Does anybody where to look or what to click?
I'm using the 2014 version (CTP2)
If you have a .sql file which contains SQL statements, you can just copy and paste the contents (or open the file in a query window) and run it. This assumes it has all of the create table etc. statements to create the schema/structure and not just insert statements for the data.
Check the top of the file to make sure that it is first selecting the correct database, if not add a USE statement to select the correct database.
You didn't say how big the file was, but if it is quite large and has the insert statements (data as well as schema), then you'll probably want to run by CLI using sqlcmd command. Much faster and SSMS won't freak out.
Another alternative option to running the .sql file/code is to set up a data source for mysql and just use odbc to access the database itself.
Bear in mind that there are real and very annoying differences between mysql and t-sql that can make migration a pain. If you're just creating a few tables, it may not be an issue, but if there are a ton of tables with lots of fields of different data types, you may run into issues.
If you are looking to import table structure, you can copy-paste the content and run inside SSMS in a query window. Beware of syntax differences with MySQL and SQL Server. You will most likely get errors. You need to convert your SQL script from MySQL dialect to SQL Server dialect (or just add them manually if they are not too many). If you set the databases to a SQL standard-compatibility mode at the very beginning, you will have much less trouble.
If you are ONLY looking just to import the data into existing tables inside the SQL Server only, you can do the same (i.e. copy-paste and run in query window). You will have less trouble with that.
Open the server, open "Databases" and right click the database, go to "Tasks" and then Import Data...
I have had the most 'trouble free' success importing to SQL via a flat file method (comma delimited .txt file), the only stipulation when creating a flat file (i.e from Access) make sure the text identifier is set to {none} and not "".
To import the file: in the SQL Server Management Studio right click on Databases and create a new database. Then right click on the new database -> Tasks -> Import Data... The import window opens: in the DATA SOURCE option select Flat File Source and select the .txt file...click NEXT. In the DESTINATION field select SQL Server Native Client 11.0 and go through the import process. This worked very well for me.
I am replacing an Access application with a web app, but the client is using SQL Server 2000, and I am using SQL Server 2008.
So, I have the database redesigned, with foreign keys, but now I need to get the data on the client's system.
Part of the problem is that they have images that are over 32k, so osql failed as the command buffer filled up.
I should be able to use osql to import the new schema at least, and perhaps all of the data except for the images.
The Export wizard just wouldn't work, even though I tried the Native SQL Driver and the OLE DB Sql Driver.
Flat files seems like a bad choice, as I don't know if it can do the images.
So, what is a good way to copy a 330M database from 2008 -> 2000?
Not sure about performance or time needed, but you could always try a tool like
Red-Gate SQL Compare / SQL Data Compare
Apex SQL Diff / SQL Data Diff
These will allow you to compare both the schema of two databases, as well as the data, and allow you to create synchronization scripts, or synchronize online.
Marc
I set the image column to null, which reduced the size of the insert statements.
This enabled me to import the data into the target database.
I have managed to get SQL Server 2005 Express up and running on my computer Ok in order to do some testing before trying this in the "Real World".
I have a fairly large MS Access 2007 Database application I need to migrate to SQL Server
retaining the "Front End" as the user interface. (The app' is already a "split" database
with a Front and Back end....)
I have done some initial testing on using SSMA to migrate my Access database To SQL
Server Express.
Clearly I don't understand some things and I thought I'd see if anyone has
any ideas.
Conceptually I thought that what needed to happen was that the Back End of the
database that resides on the server needed to be migrated to SQL server
and then the Front End re linked to the (now linked to SQL) tables in the Back End.
When I do this using SSMA I end up with renamed tables in the Back End
Access file that look something like "SSMA$myTableNameHere$local". I also
get the original table names underneath showing as ODBC linked tables.
So far so good.
BUT.... When I go to re-establish the linked tables from the FRONT END (The
user interface) all I can see is the "SSMA$myTableNameHere$local" names NOT
the original table names.(Now linked via ODBC)
I can link to the "SSMA,,,," tables but it would mean changing the names of
every table in every query and on every form and in all code on the Front
End! Not something I really want to do.
SO....
I thought I'd try to migrate the FRONT END and see what happens.
What I ended up with is a situation where, basically it works (there are
some serious errors and issues that I haven't even looked at yet... like
missing data etc.!!!!) and I still get the "SSMA$myTableNameHere$local"
tables and the ODBC linked tables with the original names.
I'm trying to understand...... Does this mean that we would do the
migration on the Front End and then just copy the same file to each user's
computer?
Another subject I'm a little confused about is that I can't link via ODBC
to SQL Server Express on the local machine (ie my computer) so I can't test
migrating the Back End and then linking to the tables via the Front End as I
have in the past in more of a client/server situation.
Assuming that SSMA replaces the tables in your back end with links to the SQL Server, all you need to do is delete the original table links in your front end and import the newly-created table links from the back end. You can then discard the back end, since it's not used for anything at all any longer.
I did transfer all my tables one by one to SQL Server 2005 fro Access DB back-end using ODBC.Instruction:
Open Access DB(back-end)
Right-click on table, you need to transfer
Scroll down drop-down box and select ODBC Databases
Select Data Source dialog box opened, Click "New" button
Create new data source dialog box opened
Scroll to the bottom and select SQL Server, Click Next
Give name to your Data Source, Click Next, Click Finish
Create New Data Source Dialog opens
Give some discription OR leave empty, Type Name of your SQL Server (you named it, when install SQL Server on your machine)
Click Next, Click Next
Check "change default database to check box
Select DB where you want your data transfer to
Click Next, Click Finish
NOTE: You need to create new DB (empty) on SQL Server, before doing all this
Now: Right-click any table, select Export, select from drop-down list ODBC, from Data Sources window select your Data Source, You created, Click OK
Use SQL Server with SQL Management Studio Express.
All dates must have a input mask; all text and Memo must have Allow Zero Length =Yes
After all disconnect all links from Access back-end, and establish links from SQL.RENAME all newly linked tables to old names. Use Fron-end user interfase, until do some new.
Forgive my lack of knowledge of Acronym Soup, but I assume SSMA is the SQL Server 2005 "import data wizard" or the wizard in Access to send the data to SQL Server. It appears that you sent the data to SQL Server from Access - something you don't want to do. You want to use the DTS in SQL Server (now called SSIS or something?) to import the data into SQL Server. Then you'll have your tables in SQL Server. Then, simply create your DSN entry for the SQL Server and re-link your tables. All should be well.
Overall, the general rule is to import Access tables using SQL Server instead of using Access to send the data to SQL Server.
I'd bite the bullet and rename the tables on the SQLServer side back to the friendly names that you had in the original database. You'll probably have less problems. Especially if you have any embedded code the MS Access side.
As far as how you will deploy the MS Access side now, it should be pretty much create the ODBC link on the user's workstation, and copy the MS Access file to their desktop (although you might want to make an MDE (or the 2007 equivalent) to prevent them from accidentally breaking it).
Frankly, now that you have migrated, you need to look at the design of your tables. It is my experience that the wizards for Access migration do a poor job of selecting the correct datatype. For instance if you had a memo field, you might easily get away with a varchar field instead but the last wizard I used (an earlier version) always converted them to text fields. Now would also be the time consider some fixes such as making date fileds datetime instead of character based if you have had that mistake in the past.
I would never consider using a wizard again to do data migration myself having experienced how very badly they can do it.
You will alos find that just converting the data to SQL Server is often not eough to really get any performance benefit. YOu will need to test all the queries and consider if you can convert them to stored procs instead if they are slow. Eliminating the translation from Jet SQL to T-sql can being performance improvements. Plus there are many features of t-sql that can imporve performance that do not have Access equivalents. Access is not big on performance tuning, but to get the benefit of performance tuning with a SQL Server backend, you need to have SQL Server specific queries written. INdexing needs to be considered if the Access tables were not indexed properly.
Using SSMA is different when you use odbc. If you have an application using fully access (back end and front end). You can manipulate objects easily bounding forms, using DAO, etc.. without problem, then when u need to migrate database to sql server u can use directly odbc (by linking yourself tables to sql server), ssma, ... the main problem how to preserve bounded forms, queries, code in the client-side.
If U use directly odbc you must relink by yourself all objects and change code but if u use ssma, you have to do nothing, you will continue to work as u did before. The problem with SSMA is how to deploy the front end to the clients if you developed client side in other place using another sql server?