My code and the Linq to sql function SubmitChanges are working, but when using a local database a copy of the database in the bin folder is updated and not the primary database. So the changes aren't shown on a new query. If I re-connect the database but don't load it as local same problem - the primary database isn't updated, but now I can't figure out which one is (tks to this question).
What setting for a local db or how do I use a non-local database to show changes on a new query of the database?
Dim DATA As New lnqPolarisDataContext
Dim newBOOK As New BOOK()
newBOOK.ID = 14
newBOOK.LEG = 11
newBOOK.P_C = "C"
newBOOK.STRATEGY = "STRADDLE"
newBOOK.STRIKE = 999
newBOOK.CONTRACT = "XXX"
DATA.BOOKs.InsertOnSubmit(newBOOK)
DATA.SubmitChanges()
... new query doesn't show these changes
maybe this is the best method?
The real solution in my opinion would be to put your database on the server where it belongs - after all, SQL Server is a server-based solution, not a file-based "database".....
install SQL Server Express (and you've already done that anyway)
install SQL Server Management Studio Express
create your database in SSMS Express, give it a logical name (e.g. YourDatabase)
connect to it using its logical database name (given when you create it on the server) - and don't mess around with physical database files and user instances. In that case, your connection string would be something like:
Data Source=.\\SQLEXPRESS;Database=YourDatabase;Integrated Security=True
and everything else is exactly the same as before...
Also see Aaron Bertrand's excellent blog post Bad habits to kick: using AttachDbFileName for more background info.
Related
I’m trying to copy a SQL Server table, schema and data, from Server A to Server B. The SQL Server table is just a reference table which hasn't been populated for some reason on Server B. Can anyone advise how the entire table could be copied across please? On SQL Server 2000/2005.
So far we've tried a long-winded approach by copying the .mdf and .ldf files from Server A to Server B with a plan to then copy the table across into the Server B database but we are having some difficulty re-attaching the database to Server B.
Please can anyone help?
Kind Regards
James
Using SQL Server Management Studio (SSMS):
In Object Explorer right click on source database name, Tasks.. -> Generate Scripts.. - opens Generate and Publish Scripts dialog. Click Next to choose objects, choose "Select specific DB objects", expand Tables, choose your table. Next, setup script destination, for example New query window and (important step!!) - click Advanced, and set "Types of data to script"="Schema and data" and "Script USE DATABASE"=False, OK, Next, Next, .. wait .. Finish. Now you have got complete SQL script to reproduce this table with data. Connect to destination DB and run it.
Tested with SSMS 2014, but as I recall this feature should be available starting from SSMS 2005.
you can use the import/export data wizard in management studio, the wizard will create for you a new table in the server B with the same structure of the table in the server A. before using it you need to have at least one database in sever B.
This confirms why this is one of favourite forums.
Both these methods work beautifully :
Generate Scripts (when altering Types of data to script"="Schema and
data")
Export and Import
Interestingly Generate Scripts works with SQL Express perfectly but the Export method does not save unless you have at least SQL Server Standard Edition.
Thanks so much everyone
Cheers
James
Try this:
SELECT * INTO destination FROM source
But, it will not copy the indexes and key information or you can also try import/export data task from SSMS.
I want something like :
insert into server2.database1.table1 select * from server1.database1.table1
both tables are exactly the same.
how can I Copy data between two server instances?
SQL - Linked Server
If both servers are SQL Server, you can set up Linked servers - I would suggest using an SQL account for security there.
Then you can simply perform
insert into server2.database1.dbo.table1
select * from server1.database1.dbo.table1 where col1 = 'X'
If you run the query in SQL Management studio connected to server1, and current database set to database1, you won't need the prefix
server1.database1.dbo.
Also, the linked server would be configured on server1, to connect to server2 (rather than the other way around).
If you have the correct OLE DB drivers, this method can also work between different types of RDBMS (ie. non-SQL Server ones).
Open Query
Note: Beware not to rely on linked servers too much especially for filtering, and for joins across servers, as they require data to be read in full to the originating RDBMS before any conditions can be applied. Many complications can arise from Linked Servers, so read up before you embark, as even version differences might cause headaches.
I recommend you use the OPENQUERY command for SQL Servers to get around such limitations. Here's an example, but you should find help specific to your needs through further research:
insert into server2.database1.dbo.table1
select * from OPENQUERY(server1, 'select * from database1.dbo.table1 where col1 = ''X''');
The above code is more efficient, filtering the data on the source server (and using available indexes), before pumping the data through, saving bandwidth/time/resources of both the source and destination servers.
(Also note the double quote '', is an escape sequence to produce a single quote.)
SQL - Temporarily on the same server
Would enable (note the underscore):
insert into server2_database1.dbo.table1
select * from database1.dbo.table1
Still within the SQL query domain. If you can temporarily move the database on server2 to server1, then you won't need the linked server. A rename of the database would appear to be required while co-locating on server1. Achieving such co-location could use various methods, I suggest shrinking database files before proceeding with either:
Backup/Restore - Backup on server2, Restore on server1 (with different name) - perform insert as described above, but without the server1 or server2 prefixes. Then reverse - backup on server1, restore on server2/
Detach/Attach - Rename database, Detach on server2, (compress), copy files to server 1, (decompress), attach on server1, perform insert. Then reverse...
In either case, SQL Server version could be a barrier. If server1 is of a lower SQL version, then both backup and detach/attach methods will likely fail. This can be worked around by moving the server1 database to server2, which may or may not be more suitible.
Other Methods
May be suitable, non-SQL/TSQL method failing favorable environmental factors for previously mentioned methods. And if you have the correct access (OLE DB Drivers, etc..), this method can also work between different types of RDBMS (ie. non-SQL Server ones), and data-sources (such as XML, flatfiles, Excel Spreadsheets...)
SSIS Explicitly with Business Development Management Studio - direct datapump or using delimited file intermeditary.
SSIS Implicitly through SQL Management Studio, by right clicking the database1 on server1 > Tasks > Export, then completing the wizard. May work direct to server2, or using a flat-file intermeditary.
.Net Programming with SqlBulkInsert (I believe the SSIS datapump uses such an object), I can go into more detail about this, if it interests you.
Eg. of SQLBulkInsert (psedo-C# code)
SqlConnection c = new SqlConnection("connectionStringForServer1Database1Here");
SqlConnection c2 = new SqlConnection("connectionStringForServer2Database1Here");
c.Open();
SqlCommand cm = new SqlCommand(c);
cm.CommandText = "select * from table1;";
using (SqlDataReader reader = cm.ExecuteReader())
{
using (SqlBulkInsert bc = new SqlBulkInsert(c))
{
c2.Open();
bc.DestinationTable = "table1";
bc.WriteToServer(reader);
}
}
Pretty cool huh? If speed/efficiency is a concern - SqlBulkInsert based approaches (Such as SSIS) are the best.
Update - Modifying the destination table
If you need to update the destination table, I recommend that you:
Write to a staging table on the destination database (a temporary table, or proper table which you truncate before and after process), the latter is preferable. The former may be your only choice if you don't have CREATE TABLE rights. You can perform the transfer using any one of the above options.
Run a MERGE INTO command as per your requirements from the staging table to the destination table. This can Insert, Update and Delete as required very efficiently.
Such a whole process could be enhanced with a sliding window (changes since last checked), only taking recently changed rows in the source an applying to the destination, this complicates the process, so you should at least accomplish the simpler one first. After completing a sliding window version, you could run the full-update one periodically to ensure there are no errors in the sliding window.
To copy data between two different servers you have several options:
Use linked servers.
Use the data import export wizard.
Use a third party tool such as Red Gate SQL Data Compare.
Similar to Todd C# SqlBulkCopy
Generally this is easier than creating linked servers.
Create a unit test and run the below, if you have triggers then be careful and you will need ALTER permissions.
[Test]
public void BulkCopy()
{
var fromConnectionString = #"fromConnectionString";
var destinationConnectionString = #"destConnectionString2";
using (var testConnection = new SqlConnection(fromConnectionString))
{
testConnection.Open();
var command = new SqlCommand("select * from MyTable;", testConnection);
using (var reader = command.ExecuteReader())
{
using (var destinationConnection = new SqlConnection(destinationConnectionString))
{
using (var bc = new SqlBulkCopy(destinationConnection))
{
destinationConnection.Open();
bc.DestinationTableName = "dbo.MyTable";
bc.WriteToServer(reader);
}
}
}
}
}
}
The best way to do this would be to create a "linked server".
And then you can use below statement into your insert statement in order to define your table
[linkedserver].databasename.dbo.tablename
On Server A add a linked server (B)
http://msdn.microsoft.com/en-us/library/ms188279.aspx
Then you can transfer data between the two.
Export table data from one SQL Server to another
HTH
First You need to add the server
Eg. Server 1 and Server 2
sp_addlinkedserver 'Server-2'
then copy your data from that server to your server by using following query
In Server-1 Write
select * INTO Employee_Master_bkp
FROM [Server-2].[DB_Live].[dbo].[Employee_Master]
If you need an alternative without using Linked Servers, my favorite option is use the command line BCP utility.
With this bulk copy tool, you can export the data to a flat file, copy the file across the network and import it (load it) onto the target server.
https://learn.microsoft.com/en-us/sql/tools/bcp-utility
I have database connection to database DB1. The only thing I could do - execute any t-sql statements including using stored procedures. I want to export the specific table (or even the specific rows of specific table) to my local database. As you can read abve, DBs are on diffrent servers meaning no direct connection is possible. Therefore question: Is it possible to write query that returns the other query to execute on local server and get data? Also note, that table contains BLOBs. Thanks.
If you have SQL Server Management Studio, you can use the data import function on your local database to get the data. It works as long as you have Read/Select access on the tables you are trying to copy.
If you have Visual Studio you can use the database tools in there to move data between two servers as long as you can connect to both from your workstation.
Needs Ultimate or Premium though:
http://msdn.microsoft.com/en-us/library/dd193261.aspx
RedGate has some usefull tools too:
http://www.red-gate.com/products/sql-development/sql-compare/features
Maybe you should ask at https://dba.stackexchange.com/ instead.
If you can login to the remote db (where you can only issue t-sql), you may create linked server on your local server to the remote and use it later directly in queries, like:
select * from [LinkedServerName].[DatabaseName].[SchemaName].[TableName]
what is mssqlsystemresource database? do we need to copy this while moving form one server to another one?
All system stored procedures, views and functions are stored in the MsSqlSystemResource database. This db is hidden, you can't see it in SSMS but lives in the data directory...should already be on your new server
run this query on the other server
select name, filename
from master..sysaltfiles
where dbid = 32767
The system resource database. You should treat it as part of your SQL Server binaries, not as part of your data. You should never copy this file, it is manipulated only by SQL Setup operations. Replacing a resource database is not supported and can render a SQL Server instance unusable.
Ok here is the thing:
I have an old MS SQL 2000 server, and this one will keep running.
however for a new website i have a SQL 2008 server.
I need 3 tables from the old server (lets call it www.oldserver.com) to be on the new server too. the data on the old server still changes daily.
I would like to update the tables immediately when something changes on the old server.
how do you do this. i looked at mirroring but that doesnt seem to be the way to go, now i've checked Import function in SQL Server management studio, but i dont want to import the data all the time. 1 import, then updated like daily are ok. so i guess i need to 'write a query to specify the data to transfer' but i have no idea how that query should look.
the import will go to a SSIS package so it can be scheduled.
what is the best practice here? how should i do it?
You could set up the old server as a Linked Server in the new server.
Then, you could create the tables on the new server not as tables, but as views, directly selecting from the tables on the old server.
Like this (on the new server):
create view OldTableOnNewServer as
select * from OldServer.OldDatabase.dbo.OldTable
Advantages:
no replication/updating necessary -
the data comes directly from the tables on the old server
Disadvantages:
Network traffic: each time someone
selects from the view, the new
server will access the oldserver
over the network
Availability: if the
old server is not available, the
views on the new server won't work at all