I am working for a company that uses Gmed EMR. Gmed lacks some features that my client requires and I have had to build an external secure web based application to fill in. Gmed runs on Microsoft SQL server. I have access to the server, but I've never used Microsoft SQL server before. How can I safety SQL dump the users tables? Should I even try this?
To get a dump, do the following (OTTOMH):
Open SQL Server Management Studio
Right click on your database
On the menu go to TASKS and then GENERATE SCRIPTS then click NEXT
Choose "Specific Objects"
Choose the tables that you want
In the options make sure you choose the option for SCRIPT DATA
Choose to put it into a script or a window and click FINISH
This will give you a script to create the table, as well as the INSERT statements for data.
If you want just the data dump, you can right click a database and choose to EXPORT data.
It depends on the format you want them in. It's pretty easy to export to a text file. Open SQL Server Management Studio (the GUI), right-click the database you want to export from, then click Export Data. It's a straightforward wizard that lets you select what tables or other objects you want to export, and in what format or to what file.
Related
I am using Visual Studio 2017.
Functionality - Open Visual Studio - Go to Tools - Click SQL Server -
New Data Comparison
After mentioning source and target database and running the tool, I get results -
(Different Records, Identical Records)
Is there a way to export this data result to Excel?
Harshit Virdi has noted he has access to Microsoft SQL Management Studio. There are two easy ways I know of to export results into Excel:
Option 1 the "right click on your results" option:
Run your query like normal in Microsoft SQL Management Studio. Then right click on the results like this:
.
Choose "Save Results As..." and if you pick CSV (comma separated value) you'll be able to open that in Excel.
Option 2 would be to Export from a table or view directly. Right click on the database (not the table) you want to export from, choose tasks, and Export Data...:
A wizard will appear (ha!)
Choose your Data Source (SQL Native Client)
Pick your server and database
Choose your Destination
Select Excel, and pick a path. I keep it at Excel Version 97-2003 but you can try different ones
Now you can choose to either write a query or pick a table, the choice is yours!
Hit next and finish it up and boom, you have your data in Excel.
The export data wizard is rather powerful, you can also transfer data between servers very fast and easily. It's a tool worth learning more about. You may have noticed on the last steps of the wizard you can save your 'code' as an SSIS package. That way you could run the same export again, or automate it. However that goes beyond the scope of this question. Good luck!
In SQL Server 2000 you had DTS where you had the option to choose to export table structure along with data and also to choose specific tables only. Is there a similar option in SQé Server 2005 version.
I would like to export just 5 tables along structure and data from an existing database to another database. The data is required as it contains auto increment id fields that are maintained as foreign keys.
Use right mouse click on your database >> tasks >> generate scripts
After a few times 'next', you can select the tables from which you want to export the structure.
To export the data, you can:
Right mouse click on your database >> tasks >> export data
or copy/paste from/to table data view
Yes, of course - the DTS-equivalent in SQL Server 2005 and up is SQL Server Integration Services (SSIS).
You'll find that in your start menu under the SQL Server tab called Import and Export Data.
If you need to do this operation often, you might also want to look at the bcp (bulk copy) command line tool for doing this kind of thing. This allows you to wrap the operation into a batch file and execute it regularly or on demand.
SSMS has a facility to do this available from the object explorer (somewhat counter-intuitively this is not available within BIDS). This invokes a wizard that generates an SSIS package that can export one or more tables to another database.
Right click on the node in the SSMS object explorer, select Tasks->Export Data and this will invoke the export data wizard. The rest it pretty self-explanatory.
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?
I would like to copy a table from one database to another. I know you can easily do the following if the databases are on the same SQL Server.
SELECT * INTO NewTable FROM existingdb.dbo.existingtable;
Is there any easy way to do this if the databases are on two different SQL Servers, without having to loop through every record in the original table and insert it into the new table?
Also, this needs to be done in code, outside of SQL Server Management Studio.
Yes. add a linked server entry, and use select into using the four part db object naming convention.
Example:
SELECT * INTO targetTable
FROM [sourceserver].[sourcedatabase].[dbo].[sourceTable]
If it’s only copying tables then linked servers will work fine or creating scripts but if secondary table already contains some data then I’d suggest using some third party comparison tool.
I’m using Apex Diff but there are also a lot of other tools out there such as those from Red Gate or Dev Art...
Third party tools are not necessary of course and you can do everything natively it’s just more convenient. Even if you’re on a tight budget you can use these in trial mode to get things done….
Here is a good thread on similar topic with a lot more examples on how to do this in pure sql.
SQL Server(2012) provides another way to generate script for the SQL Server databases with its objects and data. This script can be used to copy the tables’ schema and data from the source database to the destination one in our case.
Using the SQL Server Management Studio, right-click on the source database from the object explorer, then from Tasks choose Generate Scripts.
In the Choose objects window, choose Select Specific Database Objects to specify the tables that you will generate script for, then choose the tables by ticking beside each one of it. Click Next.
In the Set Scripting Options window, specify the path where you will save the generated script file, and click Advanced.
From the appeared Advanced Scripting Options window, specify Schema and Data as Types of Data to Script. You can decide from here if you want to script the indexes and keys in your tables. Click OK.
Getting back to the Advanced Scripting Options window, click Next.
Review the Summary window and click Next.
You can monitor the progress from the Save or Publish Scripts window. If there is no error click Finish and you will find the script file in the specified path.
SQL Scripting method is useful to generate one single script for the tables’ schema and data, including the indexes and keys. But again this method doesn’t generate the tables’ creation script in the correct order if there are relations between the tables.
Microsoft SQL Server Database Publishing Wizard will generate all the necessary insert statements, and optionally schema information as well if you need that:
http://www.microsoft.com/downloads/details.aspx?familyid=56E5B1C5-BF17-42E0-A410-371A838E570A
Generate the scripts?
Generate a script to create the table then generate a script to insert the data.
check-out SP_ Genereate_Inserts for generating the data insert script.
Create the database, with Script Database as... CREATE To
Within SSMS on the source server, use the export wizard with the destination server database as the destination.
Source instance > YourDatabase > Tasks > Export data
Data Soure = SQL Server Native Client
Validate/enter Server & Database
Destination = SQL Server Native Client
Validate/enter Server & Database
Follow through wizard
I need to upsize a split Access database, i.e., one that's currently split between tow mdb files, a front-end and back-end. I see many webpages that in essence say, "run the Upsizing Wizard." My first, very basic question:
Should I be running this wizard in my front-end mdb or my back-end mdb?
I assume I don't want to link main mdb -> backend mdb -> sql server. Should I run the wizard on the backend mdb, and then in the frontend mdb change the linked tables to point to sql server rather than to the backend mdb? If so, how is this done? When I right-click and go into the Linked Table Manager for a table in the frontend (linked to the backend md), it only seems to let me choose a new mdb file.
I would agree with your first guess: you will want to run the wizard on the back-end mdb.
Once that's in SQL Server, also as you guessed, you'll want to link the front end to work with the SQL Server data. One way to do this is to set up an ODBC data source for your new SQL Server database and select that in the Linked Table Manager.
Open the Data Sources (ODBC) shortcut: in XP Pro, this is in the Control Panel under Administrative Tools. (If you don't see it, you probably don't have permission to create a data source, so you'll have to work with your network people to do this.) This will open the ODBC Administrator.
On the File DSN tab, click Add.... You'll see a list of available drivers. Select SQL Server and click Next. (If the front end is only being used on your machine, you can create a System DSN instead.)
Find a common location and name your data source.
Click Next and Finish. This will set up the first part of the data source, and will open the SQL Server data source wizard.
Name the data source and select the server on which you've put the upsized back-end database.
Change the rest of the settings as needed (you may not need to change much, but the scope of those changes may require a second question) and click through to Finish.
Once you have the data source set up, then Get External Data should give you the option to select it as your source. (In 2007, you can get there from the External Data ribbon. ODBC data sources are available under More.)
To expand a little further based on Matt's follow-up questions:
How you do it is a design choice. I recommend upsizing the back-end mdb because that would allow you to keep whatever forms and such you had in Access; I think it's less of a transition if your data is in SQL Server.
Before you upsized, your tables were linked to the back-end database, and the Linked Table Manager showed the links. After you set up the ODBC data source and linked those tables, it'll show that link. You'll view the links in two different ways because they're actually different types of links (Access vs. ODBC), even though the links may look the same in your front-end mdb.
Personally I have found that the upsizing wizard does a very bad job of determining correct datatypes. I would create the tables myself in SQL server using the datatypes I need, then move the data to the existing tables from Access. other wise you will be stuck with text data when you could use varchar or float when you really need decimal.
Once the data has been moved then I would delete the Access tables and link to the SQL Server tables.
Do not do anything without having a backup copy of the database first.
As a matter of standard paranoia, I would just make a backup copy of the existing files and run the Upsizing Wizard on the front end. If anything undesirable happens, just revert the changes by overwriting with the backup copy.
Update the front end, and it will import the back end tables before it upsizes. I did this a week ago with a successful result.
However, any queries that use -1 instead of Yes will fail. Any full table deletes on tables without a primary key will fail, and you will get different behaviour from that than you will by merely using a pass-through SQL query to truncate table. The trunc will delete all rows, the Access version may leave a blank.
Also you'll need to include dbSeeChanges anywhere you have a recordset opening on a table with an autonumber column data type. SQL changes these to Identity data types, then gripes before you try to open the table. Good luck.
Do it all in the front end
You can simply export the tables to SQL Server.
You can then delete the linked tables you have in your frontend.
Then link the connection to SQL Server
Check:
when you open tables you get records
all your queries run
compile your code
You will also have to consider how you are releasing the front end. If you are using a dsn file you will need to provide that to each user.
You will need to determine how the end user accesses SQL Server. Are you using a single login with the username and password stored in the connection?
You could also split your backend DB into multiple Access DB and link them in the frontend.