Is there a way to replicate only schema (and all schema objects) without data between two SQL server instances?
For copying, rather than replicating, the simplest way would be to "Create scripts" for the database and run them on target server. This will create a new blank database on the new server.
Replicaton in SQL server implies that as you make changes to one schema they are automatically replicated on the other server. This can be done to some extent with SQL server replication, you just prevent he data being transferred but setting a criteria. I don't see how this would be of much use though.
I found this researching something else so I don't know if it is still an issue for you or not but there is an object in SSIS called Transfer SQL Server Objects. I haven't used it before but it has an option to copy data or not and you can select copy all objects or just specific types of objects, permissions etc.
Related
every once in a while I need to move a database from one server (QA) to another (production )
until now I used to perform backup on one server copy to the other server and then restore it...
is there a way to do it more efficiently?
maybe an automated job?
mirror? replication?
I'm searching for one-two clicks solution..
tnx.
I already made an automated script that does all of the following:
1)backup.
2)zip.
3)copy.
4)unzip.
5)restore.
Could you possible create an SSIS package (using the Transfer Database Task+ Transfer SQL Server Objects) that you can execute when you need it? You could create a 'template' package and use it for further use with just changing the connections.
See this blog post for some more details:
https://www.mssqltips.com/sqlservertip/2064/transfer-database-task-and-transfer-sql-server-objects-task-in-ssis/
From the link above:
Transfer Database Task: The Transfer Database Task is used to move a database to another SQL Server instance or create a copy on the same
instance (with different database name). This task works in two modes
[...]:
Offline : In this mode, the source database is detached from the source server after putting it in single user mode, copies of the mdf,
ndf and ldf files are moved to specified network location [...]
Online : In this mode, the task uses SMO to transfer the database objects to the destination server. In this mode, the database is
online during the copy and move operation, but it will take longer as
it has to copy each object from the database individually [...].
Transfer SQL Server Objects Task The Transfer SQL Sever Objects task is used to transfer one or more SQL Server objects to a different
database, either on the same or another SQL Server instance. This
allows you to select different types of objects you want to transfer.
You can select tables, views, stored procedures, user defined
functions etc. [...]
Not sure what it would take to make this package transferable among the different databases you may need to copy, but maybe it's worth exploring.
Good luck! :)
I'm new to SQL Server and trying to automatically update tables in SQL Server from tables in MS Access.
I have an Access database of metadata that must be kept updated for sending records to other groups. I also have a database in SQL Server which also has these same metadata tables. Currently these tables in the SQL Server database get updated manually by exporting the Access tables as Excel files, and then importing them into the SQL Server tables.
It's not the most efficient process and could lead to errors in the SQL Server database if someone forgets to check that they are using the most recent data from Access. So I would like to integrate some of the tables from Access to my database in SQL Server. Ideally I would like for the tables in my SQL Server database to be updated whenever Access is updated or at least update the tables automatically in the SQL Server database when I open it.
Would replicating the Access tables be the best? I am using SQL Server 2014 Developer so I think I have this capability. From my understanding, mirroring is for an entire database not just pieces of it. However, I do not want to be able to alter the metadata from SQL Server and have it reflected in Access. I cannot tell if reflecting the tables would do this...?
I also looked at this post about writing multiple insert statements but was confused (What is the best way to auto-generate INSERT statements for a SQL Server table?). Someone else suggested importing all the data into SQL Server and then using an ODBC driver to connect the two, but I'm also not sure how this would update the database in SQL Server anytime Access is updated.
If you have any suggestion and a link to easy to follow tutorial I would really appreciate it!
Thanks
In Access, go to 'External Data', ODBC Database, and connect to the SQL Server database directly - make sure you select 'Link to the data source by creating a linked table' on the first page of the wizard. Now, this linked table is available in Access, but is actually the SQL Server table.
Get rid of the local Access tables, using the new linked tables in their place in whatever queries, forms, reports, etc that you have in Access.
Now, any changes to the tables you see in this Access db ARE changes to the SQL Server database.
I have an access 2003 database that holds all of my business data. This access database gets updated every few hours during the day.
We're currently writing a website that will need to use the data from the access database. This website (for the time being) will have only read only capabilities. Meaning there will only need to be one way transfer of data (Access -> SQL).
I'm imaging there's a way to perform this data migration from access to SQL server programatically. Does anyone have any links to something I can read about?
If this practice sounds odd, and you'd like to suggest another way to do this (or a situation where data can go both ways (Access -> SQL, SQL -> Access), that's perfectly fine.
The company is going to continue using Access 2003 for their business functionality. There's no way around that. But I'd like to build the (readonly) website on top of SQL Server.
The strategy you outlined can be very challenging. You could use INSERT queries to copy new Access rows to SQL Server, as described in another answer.
However, if you have changes to existing Access rows, and you also want those changes propagated to SQL Server, it won't be so simple. And it will be more complicated still if you want deleted Access rows deleted from SQL Server, too.
It seems more reasonable to me to use a different approach. Migrate the data to SQL Server once. Then replace the tables in your Access database with ODBC links to the SQL Server tables. Thereafter, changes to the data from within your Access application will not require a separate synchronization step ... they will already be in SQL Server. And you won't need to write any code to synchronize them.
If your concern is that the connections between the web server and SQL Server be read-only, just set them up that way. You can still independently allow read-write permissions for your Access application.
To do the initial data migration and set the SQL Server automatically, I would use the SQL Server Migration Assistant. The only thing you should definitely change that I can think of would be to turn off the Identity property on any columns that have it - to be explained below (MS Access calls Identity autonumber). Once you have your tables loaded, you can set up a dsnless connection to the database (and tables) you just created.
I haven't used the method just linked, but I believe it allows you to use SQL Server authentication to connect to the db. The benefit of using this method is you can easily change which SQL Server instance and/or database your are connecting to for development and testing.
There might be a better, automated way, but you can create several insert queries doing left joins from the primary key of the Access table to the SQL Server table, and putting a WHERE clause that specifies the SQL Server PrimaryKey must be null. This is why you need to turn off the Identity property in the SQL Server tables, so that you can insert the new data.
Finally, put the name of each query in one function, then run the function periodically.
I have used Microsoft's free SQL Server Migration Assistant (SSMA) to migrate Access to SQL Server. The tool is very simple to use. The only problem I have encountered with the tool was overloaded data types when migrating. What I mean by this is a small string will get converted to a NVARCHAR(MAX) in some instances. Otherwise, the tool is very handy and can be reused after setting up a 'profile'.
I am attempting to keep a table in Sql server updated from an access table. Any time a change is made in the access table I would like that change reflected in the sql server table. The two tables can be identical. I have created an ODBC connection from access to sql server and can export the table to sql server; I just don’t know what must be done to keep that table updated. Any suggestions are appreciated.
Should this be implemented from within Access or within sql server?
Can you just add the SQL Server table to the Access database as a linked table? (Useful article on how to add linked tables)? That way users (let's hope there's not many!) of the Access database are in effect editing the SQL Server table directly.
If this isn't desirable then how about creating another table in the SQL Server database, and adding this to the Access database as a linked table. Then, add a trigger so that when an insert/update/delete is made to this table the same operation is done on your main table.
I think setting up a Linked Server in SQL Server could be easier to implement than an automatic export of data from Access.
According to the MSDN page,
Many types OLE DB data sources can be configured as linked servers, including Microsoft Access and Excel.
Server-on-SQL-2005-Server/
Access has no "event" that occurs when a row is updated/inserted/deleted that I know of. as JeffO points out data macros that could do what you want.
You could also periodically synch them. There are several techniques to periodically do the synch task (SQL Server Agent, Windows Service, Windows Scheduler, a timer in an application etc.), but still have to deal with all the problems that exist with synchronization if both tables can be modified, the worst being data conflict resolution. There is no easy solution for that.
Perhaps if you explained the problem you have that you are solving with synching data in SQL server and Access someone might be able to point you in the direction of a solution that doesn't have these problems.
I have two databases, one on a remote server the other local. (SQL Server 2008)
The database on my local server has the entire structure setup but no data. I would like to copy the data from the remote server to my server and I am wondering the best method in which to do this.
The main issue I am experiencing is the user that I have to the remote database has limited permissions. I cannot read the stored procedures, user defined functions so when I use Import/Export wizard I do not get the schema etc. So a regular dump/restore is not working for me as it restores the tables without the Primary Keys/Foreign Keys and the stored procedures.
I'd like to do this,
INSERT INTO localtable SELECT * FROM remotedb.table
I was having issues because of the IDENTITY fields and I had to explicitly name all of the columns. Also I am not sure if SQL Server Management Studio allows you to use two different databases, remote and local, so I was looking for any advice.
I have also tried applications like SQL FTP and Backup and it fails because it runs out of memory (I have 16GB of memory on the machine and the DB is like 4GB). I also can use the SQL Server import/export wizard but then I don't get the schema information. I also tried SQL Compare from Red Gate and it runs into issues with the permissions. Unfortunately I do not have the time to request and gain access to a new user so I was hoping someone had a creative idea.
You can definitely use SQL Server Backups for this. It will not run out of memory. If it does please tell us the message (because likely you are misinterpreting it). This is the fastest possible and the most complete solution.
You can tell the export wizard to also script the schema. It is hidden under "advanced" somewhere (terrible UI). But the script will be extremely big and I know of no way to execute it.
You can drop all schema objects except PKs in the target database. Then you can use remote queries to copy all the data over. You will not get any problems with foreign keys and identity columns if you drop the beforehand. After you are done you can recreate all those objects. It is probably best if you use a transaction for all of this because that way you get consistent source data from a point-in-time.