I'm trying to pull data from an ODBC app to SQL2005(dev ed) DB on an hourly basis. When I run SSIS the option to import all tables and views is grayed out and forces your to write a query. How would I go about setting up a SSIS integration service to update ALL 250 some tables on an hourly basis.
What kind of database is your ODBC data source pointing to? SSIS might not give you a GUI for selecting tables/views for all DB types.
perhaps you could rephrase your question a little, I am not 100% sure what you are asking here. Are you trying to get data into SQL Server from an application via SSIS with the Data Transform task using an ODBC connection to the Application?
Anyhoo, the simple answer to the MS Access part of your question is "hell no" MS Access is never, ever the answer to anything ;-)
I would be inclined to find out why the tables and views are greyed out and fix that issue. (not enough info in this question to determine why they are greyed out)
You might be better off using the Import and Export Wizard. Go into SQL Server Management Studio, right click on the Database you want to import the data into, and select Tasks -> Import Data. It will launch the wizard which will walk you through defining the import process.
At the end of the wizard you can choose to execute the import, and even save it as an SSIS package which you can tweak later.
Related
I pull data down from an Azure based SQL Server every now and then using the SQL Server Import and Export Wizard (which I already know isn't the best way to go about that...in the queue to change but not for now). I was wondering if there is a way to add user ApplicationIntent=ReadOnly somehow like you would in a standard SQL Server Connection string so I hit one of the read only secondary databases instead of the high trafficked main one. I'm going to go ahead with no there is not you are doing it wrong but I thought I'd ask first.
Thanks.
Don't beat yourself up for using the Import/Export Wizard - for quick and dirty /one-off ETL work, it's a great tool. Under the hood, it uses SSIS. But by design it is a wizard and so is not going to give you all of the knobs to turn.
But all is not lost! To answer your question about using read-only application intent, at the point right before you'd actually run the ETL through the wizard, it gives you the option to save the SSIS package rather than run it. Save it off and then you have the option of changing the connection however you'd like. This Q/A over on the DBA sibling site shows you how to get a read-only connection in SSIS.
If that all seems roundabout, the suggestion from #Stu in the comment above of just determining the name of the secondary replica and using that is a great one given the one-off nature of Import/Export Wizard work.
I want to know how to convert an Access database file into a SQL Server (.mdf file) database?
The MS Access "Upsize Wizard" was discontinued with Access 2012. SQL Server Migration Assistant (SSMA) is now recommended. Reference: https://accessexperts.com/blog/2013/01/30/access-2013-is-here-but-wheres-the-sql-server-upsizing-wizard/
However, as Johnny Bones noted, I found it relatively easy to create a new empty SQL Server (2012) database and then import:
SQL Server Management Studio, R-click on the newly created Database | Tasks | Import Data -> SQL Server Import Wizard
I used "Access Database Engine" instead of "Jet Database Engine" for
no reason other than I GUESSED Jet was older. Mine is a throw-away
project you may want to research the difference.
I 'weeded out' the
Access queries (views) and just imported the tables.
So far it looks
like everything was imported OK.
The simple answer is; you can not "convert" an Access database to a SQL database. You can, however, import the Access database (tables only) into SQL. Remember that SQL is a true database, and, as such, contains no front end or GUI creation mechanisms. You will still need Access (or C# or VB or another front-end builder) to create the interface.
You may already know this, but in SQL Server a Query is called a View, and Modules are called Stored Procedures. You will need to convert your Access queries and modules accordingly if you're planning on having that all reside server-side.
It's actually pretty easy to import Access tables into SQL Server, you would just create a database on a server, right-click on the database name and choose Tasks --> Import Data. There you will choose Microsoft Access as your Data Source. The rest should be pretty self-explanatory.
JonnyBones wrote a good full answer. Other have made suggestions for tools which may work. However, the SSMA (SQL Server Migration Assistant) is likely to be the best option now. (See this youtube video for help with understanding some of the issues to overcome and an explaination of how to use SSMA.
Befre you consider using other tools, which may do more, you should find out why to use them instead of SSMA. Check out the youtube video as a starting point.
Be aware that the MS Access Upsizing wizard was great but is now discontinued, and there was a bit of a gap before MS created a decent version of SSMA, which is when&why these other tools came into existence.
SSMA should do what you need.
There are some access things that do not get moved to SQLServer and some that do.
eg Access triggers do not. Access tables constraints do, Access boolean datatypes so - of sorts - but you need to do some work. The video will explain most issues well.
Harvey
You can try with the Upsize Wizard or copy content of the table from SHOW TABLE DATA and paste to the target table with the same structure as the source.
I am trying to create a MDF (Microsoft SQL Server Database) from some files located at http://archive.ics.uci.edu/ml/machine-learning-databases/census1990-mld/
Can anyone help me with the steps to do this?
I would recommend importing the data into a new database. Open up SQL Server Management Studio, create a new database and then decide how you would like to import the data.
Probably the easiest thing to do is to right click the db in Management Studio - Tasks -> Import data... choose your flat file in the wizard and then choose your mappings.
Another option would be using SSIS packages. They aren't too hard to learn but harder than the previous option and more for repeatable processes. This article has quite a few alternative solutions as well.
I'm looking for the best approach (or a couple of good ones to choose from) for extracting from a Progress database (v10.2b). The eventual target will be SQL Server (v2008). I say "eventual target", because I don't necessarily have to connect directly to Progress from within SQL Server, i.e. I'm not averse to extracting from Progress to a text file, and then importing that into SQL Server.
My research on approaches came up with scenarios that don't match mine;
Migrating an entire Progress DB to SQL Server
Exporting entire tables from Progress to SQL Server
Using Progress-specific tools, something to which I do not have access
I am able to connect to Progress using ODBC, and have written some queries from within Visual Studio (v2010). I've also done a bit of custom programming against the Progress database, building a simple web interface to prove out a few things.
So, my requirement is to use ODBC, and build a routine that runs a specific query on a daily basis daily. The results of this query will then be imported into a SQL Server database. Thanks in advance for your help.
Update
After some additional research, I did find that a Linked Server is what I'm looking for. Some notes for others working with SQL Server Express;
If it's SQL Server Express that you are working with, you may not see a program on your desktop or in the Start Menu for DTS. I found DTSWizard.exe nested in my SQL Server Program Files (for me, C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn), and was able to simply create a shortcut.
Also, because I'm using the SQL Express version of SQL Server, I wasn't able to save the Package I'd created. So, after creating the Package and running it once, I simply re-ran the package, and saved off my SQL for use in teh future.
Bit of a late answer, but in case anyone else was looking to do this...
You can use linked server, but you will find that the performance won't be as good as directly connecting via the ODBC drivers, also the translation of the data types may mean that you cannot access some tables. The linked server might be handy though for exploring the data.
If you use SSIS with the ODBC drivers (you will have to use ADO.NET data sources) then this will perform the most efficiently, and as well you should get more accurate data types (remember that the data types within progress can change dynamically).
If you have to extract a lot of tables, I would look at BIML to help you achieve this. BIML (Business Intelligence Markup Language) can help you create dynamically many SSIS packages on the fly which can be called from a master package. This master package can then be scheduled or run ad-hoc and so can any of the child packages as needed.
Can you connect to the Progress DB using OLE? If so, you could use SQL Server Linked Server to bypass the need for extracting to a file which would then be loaded into SQL Server. Alternately, you could extract to Excel and then import from Excel to SQL Server.
I'm in the process of porting some SQL Server 2005 databases to SQL Server 2008. One of these databases has an associated import application (Windows task) which uses SSIS with a DTS package to import a large dataset from an MS Access database nightly.
In upgrading to SQL Server 2008, I discovered that I can't run the same console application which has been performing the imports due to the missing manageddts DLL in SQL Server 2008. It's several years old and in need of a rewrite for various reason, plus, I've been fairly unhappy with DTS in general. The original reason DTS was chosen was for speed (5 min import time compared to 30+ for ADO.NET).
The format of the data to import is out of my control (the client likes Access). I would also like to be able to run the import from a machine completely separate from the server hosting SQL Server and preferably with minimal SQL features installed.
Options I've considered:
Creating an Access application to connect to both databases (SQL Server and Access) and perform the import (Ugh!)
Revisiting ADO.NET to see if the original implementation was poorly written.
Updated SSIS packages.
What other technologies should I be considering for this job?
I received a suggestion that I use ADO.NET to convert the .mdb file to a bunch of flat files, then use tsql's bulk insert statement to import the flat files. If it works, I'll mark this as the answer.
EDIT:
This worked really well. Far speedier than the old DTS. One down side is that the import user must have bulkadmin rights, and the schema of the flat files must precisely match the tables, but a little coding solved the latter, and a secure, dedicated user account answers the former.
I'm fairly happy with the result.
I guess you should try SSIS. If you don't know enough of it, you will learn a new thing.