Greetings.
We are running Microsoft SQL Server 2008 on one machine with a single license. We need to create an identical development instance of a database held on this server, including tables, triggers, default values, data, views, keys, constraints and indexes.
As a temporary solution, I downloaded and installed SQL Server 2008 Express R2 along with the SQL Server 2008 Toolkit on a separate machine. I then used DTSWizard.exe and pointed it at the remote host as the data source and the local machine as the target.
Transfer of data at first appeared to be fine as the tables, indexes, etc. were created but after a little more digging, I realized it was NOT transferring/setting the default values of any fields! Many of the fields have "NOT NULL" constraints and we're interfacing with a COM API (Response RCK) which does not allow us to manually edit the queries so we're stuck with how they have interface with the database/insert entries (including the use of default values circumventing the NOT NULL constraints.)
As a second option we used the "Generate Script" option and exported all tables, constraints, indexes, default values, data, etc as a .SQL file but now I'm not sure how to load this SQL file into SQL Server because it is 4.9GB - All of which is required, no circumventing the size of this monster.
So my questions are:
- Is there a way I can make a complete copy of SQL database to another server including default values?
- Or is there a way to import a .SQL file without copying and pasting it as a New Query?
P.S: Apologize if my "Microsoft" lingo is not perfect, I'm a Linux guy familiar with PostgreSQL and mySQL.
Why not just take a complete backup of the database and restore it to the new server? That will include everything including default values?
Here is some SQL that should make it happen (edit paths and logical file names to fit your needs):
-- On the source server run:
BACKUP DATABASE [TestDb]
TO DISK = N'C:\TEMP\TestDb.bak'
WITH
NOFORMAT,
NOINIT,
NAME = N'SourceDb-Full Database Backup',
SKIP,
NOREWIND,
NOUNLOAD,
STATS = 10
GO
-- On the other server run
RESTORE DATABASE [DestDb]
FROM DISK = N'C:\Temp\TestDb.bak'
WITH
FILE = 1,
MOVE N'TestDb' TO N'C:\TEMP\DestDb_data.mdf',
MOVE N'TestDb_log' TO N'C:\TEMP\DestDb_log.ldf',
NOUNLOAD, STATS = 10
GO
and you need to move the backup file between the servers if it is not accessible over the network...
Finally came across a solution that works.
In SQL Server 2008, there appears to be a bug when either exporting a database in which DEFAULT values are not carried with the table structures.
Here is my solution for circumventing this:
Right-click on the database you wish to backup.
If "Welcome to the Generate SQL Server Scripts wizard" dialog appears, click next. Otherwise continue to next step.
Select the database you wish to transfer.
There key things to ensure you select properly are as follows:
Set Script Defaults to True
Script USE DATABASE to False
Script Data to True
Script Indexes to True
Script Primary Keys to True
Script Triggers to True
Script Unique Keys to True
Once you've finished setting other optional parameters, click Next >.
Check Stored Procedures, Tables and View (do not check Users unless you want to/need to.) and click Next >.
Click Select All to select all Stored Procedures and click Next >.
Click Select All to select all Tables and click Next >.
Click Select All to select all Views and click Next >.
Under Script mode, select Script to file.
Click the Browse... Button and select the folder and filename you wish to save the SQL script under. In this example we'll use my_script.sql.
Click Finish.
Now that we have the entire database backed up including tables, views, stored procedures, indexes, data, etc. it's time to import this data into a new database.
On the machine you wish to restore this information to, perform the following steps:
Open your command prompt by clicking Start -> Run... or Pressing Windows (Super) + R on your keyboard.
Type "cmd" without the quotes in the Run dialog and click OK.
Browse to the directory your SQL file is located at. In my case, cd "C:\Documents and Settings\Administrator\Desktop"
Type "sqlcmd -s [server][instance] -i my_script.sql" ... [server] is whatever the name of your Windows machine and [instance] is whatever the name of your SQL instance is. For SQLExpress it is "SQLEXPRESS" without the quotes.
Press Enter and you're on your way!
Hope this helps someone else who has encountered the maraud of issues!
Is possible to run a both query from a single server
-- On the source server run:
BACKUP DATABASE [TestDb]
TO DISK = N'C:\TEMP\TestDb.bak'
WITH
NOFORMAT,
NOINIT,
NAME = N'SourceDb-Full Database Backup',
SKIP,
NOREWIND,
NOUNLOAD,
STATS = 10 GO
-- On the other server run
RESTORE DATABASE [DestDb]
FROM DISK = N'C:\Temp\TestDb.bak'
WITH
FILE = 1,
MOVE N'TestDb' TO N'C:\TEMP\DestDb_data.mdf',
MOVE N'TestDb_log' TO N'C:\TEMP\DestDb_log.ldf',
NOUNLOAD, STATS = 10
GO
Related
I have postponed writing SQL code for university, and now that I want to start learning it, I have no idea how to.
In C I'd define headers and begin with coding main, but in SQL classes all I have is a plain example
CREATE TABLE Sailors(
sid INTEGER,
sname VARCHAR(30) NOT NULL,
rating INTEGER DEFAULT 0,
age REAL DEFAULT 18
)
and some commands for using the table I created.
My questions are: How is a correct script supposed to look? How do I run it to create a database? (MySQL) How do I use MySQL to run scripts and where do I type commands in real time to do stuff I haven't scripted?
I just can't wrap my head around it. All tutorials I've seen use a terminal I can't find, or another I did find and I can't use because I get errors using any command (can't create file in some directory and some modules report errors so it shuts down)
The following is a very vague description of Mysql to get an idea of it:
Mysql (or SQL) is separated in 3 types of language:
DML : Data Manipulation Language
DDL : Data Definition Language
DCL : Data Control Language
Read about them to find out which kind of command belongs where.
You will find out that you almost exclusively need DML and DDL to work with Data in MySQL. While DCL is mostly used to keep the database running, control user privileges , etc.
Also when running code there will be only one command of your script executed at a time without a possibility to point somewhere else in your script.
Loops and Cursors can be used , but have to be stored in a special form of script called stored procedure. Usually you execute your code in a sequence without a code based relation between the different commands (the relation comes from the context of the commands).
Get Data into your Database:
(Consider installing the community edition for MySQL if you have problems running MySQL correctly)
To get Data into your Database , you should import data from files into your database. The MySQL-GUIs available (Workbench, Toad, Navicat, HeidSQL...) usually provide an Import Wizard that makes it easy to import Data from all kind of Files (txt, Excel, Database Files ..).
You can create an excel spreadsheet and import it into your database for example.
here is a picture of the Workbench SQL Editor:
https://dev.mysql.com/doc/workbench/en/images/wb-getting-started-tutorial-adding-data-movies.png
Workbench (or any other GUI) will be your IDE. Getting into it will answer many of your questions.
Regarding the correct script:
A complete MySQL command is called a query.
A Query is defined by a ; at the end (default) .
A chain of MySQL commands is called a script.
Therefore, a correct script consists of correct querys.
To solve more complex problems, use stored procedures in MySQL (this should come close to your usage of the word script).
some MYSQL commands you will have to be familiar with:
select
update
insert into
delete
create table
drop table
alter table
You have a lot to read. But make sure that your Database is running and you have some data in it to test code. As you already have programming experience, you should understand this really fast with the right setup.
Want to see last executed queries in MySql Workbench whether its
create / alter table query
select / insert / update query
or any query list.
in short want to see history of all queries
From the bottom panel, change "Action Output" to "History" and then choose the appropriate date.
Alternatively, the SQL statement history is stored in text files under two locations:
sql_history/yyyy-mm-dd e.g., sql_history/2015-04-01: Full Workbench SQL history for all MySQL connections
log/sql_actions_.log*: SQL history execution results, but without the data, and separated per MySQL connection
The location of these files depends on your system. For additional details, see
MySQL Workbench Settings and Log Files
In both cases, you will see the query history.
C:\Users[WinUser]\AppData\Roaming\MySQL\Workbench\sql_history
you find a log file for each day. It includes manual and automated queries from workbench (e.g. UPDATES via edit in Table)
Suppose that you can no longer connect to a previous MySQL database instance, and you just want to see your SQL history from the editors. Do this:
Locate your MySQLWorkbench settings folder:
Windows: %AppData%\MySQL\Workbench\ -- which is usually C:\Users\your_username\AppData\MySQL\Workbench\ (Note that the AppData folder is hidden by default, so you may want to unhide AppData first, to see its contents.)
macOS: /Users/your_username/Library/Application Support/MySQL/Workbench/ (Note that the ~/Library folder is hidden by default, so you may want to unhide it first, to see the contents)
Linux: /Users/your_username/.mysql/workbench/
Open the folder sql_workspaces (inside Workbench)
You should see folders of your previous database connections. Navigate into one of them.
There should be several "*.scratch" files. They are text files of editor history of SQL queries.
Open these *.scratch files in a text editor, and copy the contents.
You will find a complete History file in:
C:\Users\[WinUser]\AppData\Roaming\MySQL\Workbench\log\sql_actions_unconnected.txt
MySQL Workbench could not open History file for some reason, but I was able to recover my unsaved queries by browsing this history file.
History of queries executed can be found by 2 ways mentioned in the following answer:
Recovering from MYSQL Workbench HISTORY
Recovering from AUTOSAVE file
https://stackoverflow.com/a/73464375/7397820
I have a local SQL Server instance on which I created a Linked Server connection to a DB2 database named "DB2OurDatabase." In creating the Linked Server connection, I specified a UID and PWD that I use in various query tools or applications to query "[SchemaX].[TableX]."
I seemed to have success in creating the Linked Server: A Linked Server node Object by the name of "DB2OurDatabase" was created under the Linked Server node in SSMS and when I expand it, I am able to see the of tables in the database.
When I right mouse click on the [SchemaX].[TableX] table and select
"Script Table as => Select To ==> New Window", a new query window was opened with the text
--[DB2OurDatabase].[DataCenterCityName2_DB2OurDatabase].[SchemaX].[TableX]
contains no columns that can be selected or the current user does not have permissions on that object.
GO
I don't understand how I was able to create a Linked Server that can see the table names in the database but yet apparently seem to encounter what appears to be a lack of rights to query the table even tghough I am using same credentials that I have used in Squirell SQL query tool, for example, to query the table.
In SSMS, I tried to execute this
SELECT *
FROM [DB2OurDatabase].[DataCenterCityName2_DB2OurDatabase].[SchemaX].[TableX]
Error:
Msg 7314, Level 16, State 1, Line 1
The OLE DB provider "IBMDADB2" for linked server "DB2OurDatabase]" does not contain the table ""DataCenterCityName2_DB2OurDatabase"."SchemaX"."TableX"". The table either does not exist or the current user does not have permissions on that table.
I was a little surprised that the fully qualified table name included [DataCenterCityName2_DB2OurDatabase] since I did not specify this when I set up the Linked Server connection, but the name of the DataCenter city was correct so I took this as a further sign that the Linked Server connection was successful.
Nevertheless, I also tried to execute remove this level of the fully qualified table name:
SELECT *
FROM [DB2OurDatabase].[SchemaX].[TableX]
which resulted in this error.
Msg 208, Level 16, State 1, Line 1
Invalid object name 'DB2OurDatabase.[SchemaX].[TableX]'.
What do I need to do to create a DB2 Linked Server that lets me query the tables in the DB2 database? Here's my linked server properties:
I haven't investigate what are probably multiple ways to conenct and query DB2 from Sql Server, but this worked:
SELECT * FROM OPENQUERY(DB2OurDatabase, 'SELECT * FROM SchemaX.TableX')
Obviously, you modified the actual commands by replacing object names, so it's impossible to be sure, but the problem may be caused by your use of quoted identifiers (those square brackets), which essentially makes the object names case-sensitive. DB2 will by default create object (table, schema) names in uppercase, unless they are quoted. create table MySchema.MyTable... (unquoted) on the DB2 side will create the table MYSCHEMA.MYTABLE, and referencing it later from SSMS as [MySchema].[MyTable] (using quoted identifiers) will obviously fail.
These are the 3 steps that bring me to the solution:
Download and install Microsoft OLE DB Provider for DB2 Version 6.0 (this is the latest version but by the time you read this post there might be a new version now)
From the start menu open the Data Access Tool > File > New Data Source and complete all the steps: provide the notorious credentials like Server, Port, Database, User, Password. If unsure contact your DBA. Once completed test the connection and copy the Connection String
Now on SSMS go to Server Object > Linked Servers > New Linked Server and fill up like in picture setting up in the Provider string the string you copied before from the Data Access Tool:
Done, you are good to go now,
I am trying to upload a 32mb MYSQL database into a pre-existing database, but the php admin on my shared hosting has a 10mb limit... I have tried zipping it up - but when the server unzips the database, the uncompressed file is too large for the server to handle.
Is it possible to split the database up and upload it by pasting it in parts as an SQL query - I assume I would need each chunk to have something at the start of it which says
"Import this data into the pre-existing tables in the database"
What would this be?
At the moment there is a few hundred lines saying things like "CREATE" and "INSERT INTO"
You might try connecting to the database remotely with mysql workbench, or command line tool mysql. If you can do that, you can run:
source c:/path/to/your/file.sql
and you won't be constrained by phpmyadmin's upload size restrictions. Most shared hosting I've seen allows it. If not, you may just need to grant permissions for the user#host in phpmyadmin (or whatever the interface is).
The dump file created by mysqldump is just a set of SQL statements that will rebuild your tables.
To load it in in chunks I'd recommend either dumping it out in sets of tables and loading them one by one or if required the dump file should be roughly in the same (pseudo) format:
Set things up ready for loading
CREATE TABLE t1;
INSERT INTO TABLE t1...;
INSERT INTO TABLE t1...;
CREATE TABLE t2;
INSERT INTO TABLE t2...;
INSERT INTO TABLE t2...;
Finalise stuff after loading
You can manually split the file up by keeping the commands at the start and finish and just choosing blocks for individual tables by looking for their CREATE TABLE statements.
So I have this gigantic table, containing approx 7 million records, in MS Access (*.mdb), I want to transfer it into a much more workable MySQL format, and store it on my webserver. The file itself weighs 2GB.
The problem is, since the table is so large, it won't let me export it normally (Access says the limit is 65,536 records.)
I've tried some 3rd party software but to no avail.
Can anyone recommend a clean way of doing so, without damaging the data inside?
Thanks in advance for any help.
Install an ODBC driver for MySQL, if you don't have one already. The latest version is available here: Download Connector/ODBC
Create a DSN (Data Source Name) for your MySQL server from the Windows ODBC Data Source Administrator.
Then from Access 2003, select your table in the Database Window, and choose File->Export from Access' main menu. In the "Export Table 'yourtablename' To ..." dialog, select "ODBC Databases()" from the "Save as type" drop-down list (at the bottom of the dialog). The next dialog allows you to specify the name MySQL will use for the exported table, and it defaults to the Access table name. After you click OK, you will get another dialog, "Select Data Source", where you can select your DSN for MySQL. After you click OK on that dialog, you will probably get one more asking you for user name and password. Supply them, and click OK.
Hopefully your table will then transfer without errors. However, I've never done that operation with MySQL. It has worked for me with ODBC transfers to SQL Server and PostGreSQL. So I don't see why it wouldn't work with MySQL, too.
Also I've never attempted to export 7 million records in one go. If it chokes, we'll have to figure out a work-around.
If you're using Access 2007 instead of 2003, look for a similar option starting with the Export section of the ribbon.
I suggested this approach because my impression is this export will be a one-time deal, so I think the Access UI export method would be easiest. However, you can do essentially the same operation with VBA code using the DoCmd.TransferDatabase Method with your ODBC DSN.
Yet another alternative would be to create a compatible table structure in MySQL, create a link in Access to the MySQL destination table (using your DSN again), then run an "append query" from Access:
INSERT INTO link_to_mysql_table (field1, field2, field3, etc)
SELECT field1, field2, field3, etc
FROM access_table;
The append query approach could be useful in case the export chokes on 7 million records. You could add a WHERE clause to limit the SELECT query's output record set to a manageable chunk size, and then repeat with a different WHERE to specify another chunk.
Is that 7 million value after a compact + repair? I mean, if each record is about 120 chars in length, you can fit 32 million records in 2 gigs.
Also, I not aware of a limit of exporting 65,000 records, but only in regards to Excel.
So, you can/should be able to export the data to a csv, and then use a bulk text import in mySql to pull that data in. So, try exporting the table as csv. That should work.
I mean, you could link a table via odbc if you have a good local connection to the sql server, but if not, then I would export to csv (it is VERY fast). I would then zip the file (they zip fantastic). Upload file to server, and un-zip, and then use bulk text import. So, such a zipped file is VERY small and will save huge amounts of transfer time.
You can also consider using tab delimited as mySql also can import those, but a simple text file should work just fine.
I would use pyodbc as described in
http://en.wikibooks.org/wiki/Python_Programming/Database_Programming
download python 2.7 from
http://python.org/
download
http://code.google.com/p/pyodbc/
modify the following coede to set myfile.mdb and MyTable according to your table and file
save the code in a file translate.py
import csv
mycsv = csv.writer(open('result.csv', 'wb'), delimiter=',',
quotechar='"', quoting=csv.QUOTE_MINIMAL)
import pyodbc
DBfile = 'myfile.mdb'
conn = pyodbc.connect('DRIVER={Microsoft Access Driver (*.mdb)};DBQ='+DBfile)
cursor = conn.cursor()
SQL = 'SELECT * FROM MyTable;'
for row in cursor.execute(SQL): # cursors are iterable
mycsv.writerow(row)
cursor.close()
conn.close()
run python translate.py
Install MySQL on your own system and upsize to it rather than trying to use your local server. Then run an append query from your MySQL to the server instance.