We're finally making the move. We have a 120GB SQL7 DB. We have purchased a new server, and running Windows Advanced Server in 64bit mode, and our Network/DB support Company has installed SQL2005 on the new server.
The existing SQL7 instance is running on an older server.
My question is, because of the size of the SQL7 DB, can I simply detach the DB from SQL7, copy it across to the new server that SQL2005 is installed on, and attach the SQL7 DB into the SQL2005 environment?
I'm not worried about transaction files moving across, as we run a real time db environment, and any back up copy is useless.
I'm importing floor machine data from SQL7 into SQL2005 using SSIS. I import the SQL7 data into a SQL2005 master table and then attempt to match the import data with the data in a current table for either update or insert of new machines. The SQL2005 master table was imported from a SQL2000 database. When I run the first Lookup import, it does not recognize the PK matches between the SQL7 import and SQL2005 master and imports all the SQL7 as new machines. The first Lookup branches to a second lookup that checks for changes in the SQL2005 master. When I run the package a second time, the second Lookup treats all the records as updates when it gets to the second Lookup, but should treat these as found. Any suggestions as to why this process is not working properly would be appreciated. Is there a way I can embed a picture of the process from SSIS in this post? Thanks
I set up the transationsal replication on SQL7.0. It did not work. Here are the messages
1 on Snapshot Agent: The process could not create file Server_namec$MSSQL7REPLdATAFTPServer_namefile_nam e. Error: Access is denied 2. On Log Reader Agent: bi replication transaction are available 3. Disribution Agent: The initial snapshot for publication "DB_Name" is not yet available.
Need to set up replication between a server in our corporate network and another outside our network. Both are NT 4 servers running SQL7 and I am instructed to configure merge replication on both ends. My questions are: Is it possible to achieve this by running tcpip(read somewhere that I would need to run MPR to load the net libraries) and configuring the firewall to allow tcp/ip on the ports we are running SQL on between the two servers?
Yesterday I set up a Transaction replication with 1 publication Server A (publisher)(push)(SQL 7) Server B (distributor and subscriber)(SQL 7)
The replication was succesful and the suscriber can get correct data.
This morning I found the Red sigh in replication mornitor/miscellaneous agents.The error message is: "The job failed. Unable to determine if the owner (domain nameuser ID) of job Agent history clean up: distribution has server access (reason: Could not obtain information about Windows NT group/user 'domain name'. [SQLSTATE 42000] (Error 8198))."
I tried to use the 'disable publishing and distribution wizard' to disable this replication, but it did not finish and the screen jusr freeze. I used the task manager to end the task.
then I check the replication monitor, the publication was gone but the RED sigh still there.
I tried to use sp_dropdistpublisher to drop a Publisher but it said "the server A is not a distributor"
I tried to use sp_dropdistributiondb to delete the distribution database. but it said "Could not drop the distribution database 'distribution'. This distributor database is associated with a Publisher."
I tried to use sp_dropdistributor to remove the Distributor . but it said "Could not drop the Distributor 'Server B'. This Distributor has associated distribution databases."
I would like to set up one way Merge replication. The only way I was able to do this was to remove the triggers off the tables manually. There seems like there should be a better way.
I'm attemting to replicate from a SQL7 box to SQL2000.
The snapshot works fine, but it fails when it tries to push the subscription to the SQL2000 box with a trust error (I don't recall the exact message). I noticed that it fails when Enterprise Mgr is configured as: "Tools/Replication/Configure Publishing, Subscribers and Distribution", Subscriber Tab, "Impersonating SQL Service Agent". It works if I change to "SA".
This is only the case when we replicate from SQL7 to SQL2K. SQL7 to SQL7 works fine with "Impersonating". Has anybody seen this behavior? Any workarounds, other than using SA?
I'm attemting to replicate from a SQL7 box to SQL2000.
The snapshot works fine, but it fails when it tries to push the subscription to the SQL2000 box with a trust error (I don't recall the exact message). I noticed that it fails when Enterprise Mgr is configured as: "Tools/Replication/Configure Publishing, Subscribers and Distribution", Subscriber Tab, "Impersonating SQL Service Agent". It works if I change to "SA".
This is only the case when we replicate from SQL7 to SQL2K. SQL7 to SQL7 works fine with "Impersonating". Has anybody seen this behavior? Any workarounds, other than using SA?
i think i have serious problem. i have almost 20,000 rows with the following conflict on a table (generated by merge replication over a period of around 3 weeks) :
'The row was updated at 'SubscriberServer3.DatabaseA' but could not be updated 'at 'PublicationServer1.DatabaseA'. Metadata mismatch'
i have 20 remote subscribers & 1 publisher. The above message originates from practically everywhere.
Besides dropping(not practical at the moment) & recreating replication to get rid of them, what else can i do to resolve this problem?? Do i have to resolve this problem row by row?? i'm at my wit's end. Please help!!
I have a distributor setup on SQL Server 2005 (9.0.3042) and am trying to create a publication on SQL Server 2000 (8.0.2040) which receives the following error in my production environment:
Msg 8526, Level 16, State 2, Procedure sp_addpublication, Line 802
Cannot go remote while the session is enlisted in a distributed transaction that has an active savepoint.
The interesting part of this equation is that I was able to get this to work without error in my DEV (development) environment and well as my QAT (test) environment. This end result was that my distributor was SQL 2005, my publisher was SQL 2000 and my pull subscriber was SQL 2005. I have been diligently comparing our production environment to my other environment and have yet to find differences.
Has anyone else seen an error similiar to this? Any insight would be appreciated.
I want to replicate from SQL2000 to SQL2005. I had configured distributor, publisher in SQL2000 and also subscriber in SQL2005. But so far no replication was done on SQL2005. I wonder SQL2000 (SP2) and SQL2005 replication will it work? Is it true that I should install Service Pack 3 and above in order to replicate my database to SQL2005.
I have setup sql 2005 transactional replication system with three machines (publisher, distributor and subscriber). Couple weeks later, publisher with publications is disconnected from replication monitor (under My Publishers €“ show X on the publisher machine name). I didn€™t change any things. Can you help for this please?
SQL2000 used to send a 2 part update using sp_msdel followed by sp_msins instead of just calling sp_msupd. I thought this used to happen on tables with compostie primary keys. Does any know know if this still occurs in SQL2005 and maybe why?
I like to know that in SQL2005 how many replication sides we can create for the same database. Can we create more that one are only one for each database.
I have a database that is about 300 gig. I am setting up replication to a reporting server. We are doing a series or mock loads and I will need drop the tables and reload the main database a few times before we go live. To do that I plan to stop replication and drop all the articles, drop the subscription, then load the new data, then reinitialize and restart replication.
The first time I tried to do this, when I drop the articles, it seems to be trying to "clean up" the distribution database on the reporting server and that is taking a couple of hours to do. The disruption database is about 40 gig.
Is this correct behavior in SQL2005 replication? Is there a way to avoid this? I have all the replication pieces scripted out and would like to just drop replication, reload, and then run my scripts to recreate replication. But this "clean up" is going to cause me a lot of headache if I don't figure out what is going on.
Am I going down the wrong road here? Is there an easier way to do this? Any comments would be great!!!!
I am investigating the feasibility of a configuration with 3 databases on SQL2005
DB_A is an OLTP database and serves up transactional publication pub_txn - with updateable subscriptions
DB_B is a subscriber database which subscribes to pub_txn
DB_B is also a publisher which serves up merge publication pub_merge
DB_C is a subscriber database which pulls pub_merge
===============================
Updates on DB_A are successfully replicated to DB_B
Howvever, when DB_C pulls updates, it doesn't find the update sent to DB_B
===============================
Updates on DB_B are successfully replicated to both DB_A and DB_C
===============================
Updates on DB_C initially failed with the error
Msg 916, Level 14, State 1, Procedure trg_MSsync_upd_course_type, Line 0 The server principal "repllinkproxy" is not able to access the database "DB_C" under the current security context.
I then changed the login repllinkproxy to be a db_owner in DB_C
I now get the error
Msg 208, Level 16, State 1, Procedure sp_check_sync_trigger, Line 23 Invalid object name 'dbo.MSreplication_objects'.
=================================
I have three questions as a result 1) Is there anything fundamentally wrong with what I am trying to achieve?
How can I copy a SQL 7 database from one server to another? Please tell me all the ways because I've tried the obvious and it doesn't work. (backup and restore - won't go from one server to another, DTS transfer object Wizard - does a whole pile of errors and doesn't do stored proceedures and trigures). Thanks for help in advance. Also, what is the email address to post to the listserv and where is the FAQ for SQL7? Most of my listserv's tell you where to post right at the bottom of the digest I get - any chance you guys would do that with this list? Thanks again.
I just upgraded my SQL 2000 server to SQL2005. I forked out all that money, and now it takes 4~5 seconds for a webpage to load. You can see for yourself. It's pathetic. When I ran SQL2000, i was getting instant results on any webpage. I can't find any tool to optimize the tables or databases. And when I used caused SQL Server to use 100% cpu and 500+MB of ram. I can't have this.Can anyone give me some tips as to why SQL 2005 is so slow?
I am unable to install 32-bit SQL Server Integration Services on the server due to something that was left behind by the 64-bit version.
I've uninstalled SQL Server 2005 64-bit and when I try to install the 32-bit version of Integration Services, I get this error: "Failed to install and configure assemblies C:Program Files (x86)Microsoft SQL Server90DTSTasksMicrosoft.SqlServer.MSMQTask.dll in the COM+ catalog. Error: -2146233087 Error message: Unknown error 0x80131501 Error descrition: FATAL: Could not find component 'Microsoft.SqlServer.Dts.Task.MessageQueueTask.ServCompMQTask' we just installed."
I can't seem to figure out how to resolve this problem with the COM+ and I can't remember if Integration Services is required.
I have some production boxes on Win 2000 32-bits OS and some production servers have been upgraded to Win2003 64-bit OS runing SQL Server 2005. There are also a number of Win2003 32-bit OS running SQL 2005.
The issue is that when linking the 64-bit production servers to the 32-bit boxes running SQL 2005 / Win 2003 OS, the linking seems to succeed, but I am unable to see a number of entries in sys.objects. Typically, these objects are User Stored Procedures.
Moreover, the linking seemed to have worked, but data extraction does not take place between the servers. However, there are no errors. The objects (user stored procs) exist on the 64-bit side, but linking does not actually happen.
Microsoft KB has addressed this in SQL 2000 case in this KB article, but has not suggested a solution for SQL 2005.
After installing SP2 we encounter a problem with MMC. When selecting a DB we recieve a RunTime error? And the DB items/properties are not shown. Is there anyone with the same problem and knows how to fix this? I search the MS site for more information but there is nothing on it.
I am going to install SQL7.0 on the current NT4.0 with SQL6.5 on it by uninstalling SQL6.5 first and then installing (not upgrading through Wizard) SQL7.0.
Here are the questions I need help with: 1. Should I convert the database after the installation of SQL7.0 or directly restore the SQL6.5 databases backup? 2. If I need to convert the databases, How and in what way? 3. Which way is better upgrade or installation?
Current system 2 x 500mhz pIII 512MB ram, System mirrored and data raid 5 30GB made from 3 disks. All server is running in CA TNG. an Asset management DB and Software Delivery database. But the poor server runns most of the time at 100% 65% being used by SqlServer process. Does/Can anyone recommend any tweaks upgrades that may let the server take a breath in and out ie will more memory speed thing up faster processors or more disk.