Does anyone know of the correct stored procedure that validates the actual code in transactional replication? I have a view that basically is a select * from table1. I changed that view to select * from table2 in the publisher and there is an error in the replication monitor (as there should be) but when I run the sp "sp_publication_validation" it validates.
sp_publication_validation does a row count and/or checksum check at the publisher and subscriber and compares the two results. If they compare as the same, the article is considered "good" and if not, it's considered "bad". Now, how does your view fit into your replication setup? Do you have the view published as an article? If so, what is the value for schema_option for it in sysarticles (at the publisher)? Also, what error are you getting in the replication monitor?
Related
In an effort to maintain versions of the databases we have in our CMDB, I have to obtain the versions of some databases deployed to our servers by a third party company.
Is there a system table, view or procedure that allows me to view information regarding recent deployments (code changes from an update script) to a SQL database?
You have three options.
First, you can build your own logging based on a table and a ddl trigger which will log each change in any procedure etc.
Second, you can track changes in one of this sys tables:
select * from sys.all_sql_modules -- Get the sourcecode of each proc (and track it)
select * from sys.objects -- Get information which object is modified at which date
Third, you can reverse engineer changes in the recent past by reading the trace log of the sql server itself and filter for drop/create events. (needed SA permission)
-- Get the current server trace file
select *
from fn_trace_getinfo(NULL)
where property=2
and traceid = 1
-- Copy value from the query above and paste it here
select *
from fn_trace_gettable('[PASTE PATH HERE!]', -1)
where EventClass IN(46,47) -- Create/Drop Object
Hopefully there is one solution for you which is helpfully for you.
But by the way. Another idea is, if your workflow allows this. Just use SSDT to create deployment packages and keep track of your changes.
Best regards,
Ionic
Should the SQL database replication stop if i delete one record in a replicated table on the subscriber end?
I remember having a replication running where the delete on subscriber would be overwritten from publisher effectively preventing you from deleting the data.
But in our new configuration it crashed the replication when we deleted one record.
It depends. If you deleted a row at the subscriber that is subsequently updated at the publisher, replication will break when the update is propagated. Why is this? If you look at how the command is replicated, it calls a stored procedure with the PK column(s), a bit mask of what columns changed, and then the list of new values for columns that changed (I'm glossing over some detail, but you can look for yourself in the subscriber database; the procedures are all there and pretty accessible). Because it doesn't re-replicate the whole row again, if it doesn't find the row indicated by the PK, replication assumes (correctly) that the subscriber is no longer in sync with the publisher and stops. As far as I know, replication has never worked in the way you describe.
TL;DR: you should treat the subscriber database(s) as read-only except by the replication process itself.
I'm using SQL 2008 and have DELETE, UPDATE & INSERT auditing enabled on table XYZ. It works great other than when I query the data:
SELECT * FROM fn_get_audit_file('H:\SQLAudits\*', default, default)
It doesn't actually show me what was deleted or inserted or updated, only that a deletion, etc ... occurred. The statement column of the above query shows this snippet:
delete [dbo].[XYZ] where ([Name] = #0)
I want it to show me what the value of #0 is. Is there a way of doing this?
From what I've found about it, SQL Server 2008's "auditing" feature is very lacking. It does not act as a traditional data audit trail, where you store a new row every time something changes (via Triggers), with complete information such as the user who made the change. It more or less just tells you something has changed without much detail. I really wish SQL Server would include full data audit trail features.
Reference
While Creating Database Audit Specification, you select operation for the Audit Action Type INSERT, UPDATE, DELETE
This result in showing us logs , saying Select or Insert or Update or Delete...But the individual value can never be seen
Example - Click here to view the Logs for Insert/Update/Delete
The SQL Server Audit tool is very powerful, however, it was never designed to record data changes (eg. col1 was changed from 'fred' to 'santa' in table 'dummy' in db 'test' by 'sa').
For this you will need Change Data Capture (http://msdn.microsoft.com/en-us/library/bb522489.aspx).
Cheers,
Mark
You can monitor the delete sentences using SQL Server Profiler. You will be able to see the changes.
Another way to monitor is using the CDC (Change Data Capture) feature in SQL Server. This feature will let you monitor changes in the tables.
Finally, there are other tools related like ApexSQL Trigger.
I had inherited this SQL Server where we put data in a table (Call TableA) on a database (DB-A). I can see the tableA in another database on the same server ( DB-B) gets the same data right away.
Any ideas how this is implemented? I am trying to see the trace but so far no luck. Any one has an idea?
At this stage I am not sure if its replication. This is a guess
It could be replication or it could be a trigger on the source table that is moving the data over.
Perhaps it is transactional replication? You should be able to go to the replication are and see if there are subscribers or publishers.
Either that or you have linked servers, and triggers are copying the data.
This is most likely happening by use of either a synonym or cross-database view. Check to see if the "table" on the other database really is a table. If it IS a table, then they've set up transactional replication between the two databases.
select type_desc from sys.objects where name = 'name_on_database_b'
I would like to present you my problem related to SQL Server 2005 bidirectional replication.
What do I need?
My teamleader wants to solve one of our problems using bidirectional replication between two databases, each used by different application. One application creates records in table A, changes should replicate to second database into a copy of table A. When data on second server are changed, then those changes have to be propagated back to the first server.
I am trying to achieve bidirectional transactional replication between two databases on one server, which is running SQL Server 2005. I have manage to set this up using scripts, established 2 publications and 2 read only subscriptions with loopback detection. Distributtion database is created, publishment on both databases is enabled. Distributor and publisher are up. We are using some rules to control, which records will be replicated, so we need to call our custom stored procedures during replication. So, articles are set to use update, insert and delete custom stored procedures.
So far so good, but?
Everything works fine, changes are replicating, until updates are done on both tables simultaneously or before changes are replicated (and that takes about 3-6 seconds). Both records then end up with different values.
UPDATE db1.dbo.TestTable SET Col = 4 WHERE ID = 1
UPDATE db2.dbo.TestTable SET Col = 5 WHERE ID = 1
results to:
db1.dbo.TestTable COL = 5
db2.dbo.TestTable COL = 4
But we want to have last change winning replication. Please, is there a way to solve my problem? How can I ensure same values in both records? Or is there easier solution than this kind of replication?
I can provide sample replication script which I am using.
I am looking forward for you ideas,
Mirek
I think that adding dateUpdated field on both tables could help. This way in your replication code a record would be updated only if dateUpdated is greater then the one already stored.
That dateUpdated field would obviously store the datetime when the original record was updated, not when the replication was performed