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.
Related
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'm used to working with SQL Server and when I want to copy a DB there, I just need a handful of clicks in the wizard and voila...a complete copy of the DB, without taking the source DB offline.
We now also have an Oracle 11g because some machines require it, and I want to make a copy of the database. Just a copy on the same server, to use as a test DB for my software development.
All instructions that I find are pages full of steps, using RMAN or not, you have to write scripts, use command line stuff...I'm amazed at how inefficient such a common task is when using Oracle.
Aren't there any easy ways of copying a DB? Maybe just exporting everything to a SQL file, then editing it to use another DB name, and then executing it again?
I see that in SQL Developer you can choose 'Database Copy...' from the Tools menu, but it asks a destination connection. How can I select a destination when creating the destination DB is the whole point of running the wizard? Or is a connection not the same as a DB?
Thanks for helping me out here!
You're generally going to need a new database to copy the data to, and the data could be copied with datapump export/import. There aren't many ways of getting around that I'm afraid, but one option that you might consider is to make more use of VM's such as Oracle's own VirtualBox, as they can be cloned very easily with an absolute certainty of byte-by-byte fidelity.
Incidentally, one problem in making logical copies (via export/import) of a database is that it's easy to end up with a different physical pattern to the table and indexes, which can lead to unexpected differences in query optimisation.
It has been requested of me to dump an entire database hosted on MS SQL Server 2005 with multiple tables for a third party to then import/use.
My first thought was to find something like mysqld_dump that would give them import commands, which lead me to the "generate scripts" with schema and data, which should work.
one concern with this option is data that has primary/foreign key requirements, does the script it creates keep this in mind, should it be no problem? I am doing a test import now to attempt to verify this; thought I would mention it.
It was suggested for quicker resolution to just dismount the database and give them the MDF file. I am not sure I like this idea, as I am not so familiar with everything that gets stored in this file. Is it a security risk to our server at all? is there references stored in this file that specifically relate to our server that may allow for damages?
My main concern is security here, as long as they get the data everyone will be happy.
Any advise or even better alternatives that i have not thought of would be greatly appreciated.
Thanks
Why don't you just backup and restore the database to a server that the 3rd party has access to, or deploy it on a server for them and restrict their access and only give them ability to run scripts and other basic permissions?
I need to automate the migration from an Access (2003) to an SQL Server DB (2005 or 2008). The upsizing should be done automatically as part of a build process.
I need that because there are 2 versions of the software, a single user rich client and a web version. Access DB is used for single user to minimize setup effort, SQL Server to improve performance and scaling with many simultanious users. Access should be the "leading" DB, meaning devs do changes in Access DB and those are propagated to the SQL server within the build process. Many changes will occur, so doing it manually is not an option.
I am new to the Microsoft world, so I dont know appropriate tools for that. What tools can I use and how? I know how to do it (by clicking) with the upsizing assistant. Perhaps I can automate that somehow?
Thanks in advance for your answers.
Cheers,
Arne
Why not use a SQL Server backend for The Access database? Then changes are only made once and all is in synch.
The problem here is that you trying to do versing with two different systems.
If all of the design changes can be done in Access, then you can simply up-size that to sql server. The problem here is do you need to modify the existing sql server databases? And, do you need this over time? Upsizing the access database will get the new version up to sql server, but it WILL NOT help for existing sql server databases.
If you need over time to have changes to tables on BOTH systems and existing systems then I would state to the access developers that ALL changes to the tables MUST be written as ddl sql. You then use the ddl executed on Access to make the changes. The developer MUST THEN AT THAT POINT take that same ddl and run it on the sql side. It might need slight modifications. They fix it to run on sql server. So, then you wind up with two scripts. One for sql server, and one for Access. In the case of access you can write a few lines of code to read and process a text file of ddl. (that same code can be used for all scripts).
That way, you build up a equivalent set of changes for each upgrade. So, simply NEVER allow design changes direct to the access tables. If you allow design changes with the table designer then you are in big trouble as you don't now know what changes need to be carried over to sql server.
However, as better recommend approach I would suggest that table desing changes are done FIRST in sql server. The reason is the table designer in sql visual studio tools allow the changes just made to be scripted to the clipboard (a simple right click). The other reason is that the table designer is VERY much like the access one. So, this is easy even for access developers with little sql server experience to use. So, that simple right click of "script changes to clip board" would create the need change script for sql server (they would save this into a file for sql server). They then take the ddl, and run it on the access side. The reason for this is the ddl might need some slight mods for Access (but, they did not have to write the ddl statement). So, this means the ddl gets written for them. This means you know the sql server ddl is correct. They then simply take that ddl and use again to change the access table also. The ddl might need slight changes for access, but that's just fine because they need the table change and then run and fix this untill the simple table change is made. So this scripted ddl would be then saved for the access update into a file also. The ddl script might need slight modifications for access so I think this approach is best. As long as this is being changed/fixed as they go along you be fine.
So over a period of changes, you wind up with two scripts that keep the changes in sync for both systems.
If you don't need changes to existing sql and access databases, then just let the access folks have at it, and then simply up size the whole database to sql server in one shot and you done.
I can't really think much of any other approach between the above two extremes.
You could have the users make the change in access and then go to sql server to make the change in the sql table design and then save the sql server change script. However, this would not get you a change script for the access side. If a change script is NOT needed for access side then this would work very well as you would get a sql server change script.
The above would be how I go about this and it quite workable...
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.