I don't have much experience on SQL replication(SQL Server 2014). My client have a replication process which was created by his previous contractor. It worked well and suddenly it stopped replicating DDL statements couple of days ago. We have not done any change related to replication. When I checked data, subscriber has received up to date data. Only DDL statements have the problem. It uses transactional replication.
When I searched on web it says that the "Replicate schema changes" option need to set as true on Publication Properties.In my case it was already set to true.
Is there anyway for me to fix this and again have DDL statements to replicate as earlier?
Thank you
SQL Server Replication does support schema changes, but not all of them. In your case, CREATE PROCEDURE is not a supported schema change. Why? It's not an article yet, and not marked for replication, thus it cannot be replicated - replication has no way of knowing whether or not you would want that object replicated.
However, if you create the stored proc, then create an article for it, then issue an ALTER PROCEDURE, you will see the change replicated.
Please see article Make Schema Changes on Publication Databases:
Replication supports a wide range of schema changes to published objects. When you make any of the following schema changes on the appropriate published object at a Microsoft SQL Server Publisher, that change is propagated by default to all SQL Server Subscribers:
ALTER TABLE
ALTER TABLE SET LOCK ESCALATION should not be used if schema change replication is enabled and a topology includes SQL Server 2005 or SQL Server Compact 3.5 Subscribers.
ALTER VIEW
ALTER PROCEDURE
ALTER FUNCTION
ALTER TRIGGER
ALTER TRIGGER can be used only for data manipulation language [DML] triggers because data definition language [DDL] triggers cannot be replicated.
Please ensure you read the whole article, to be fully aware of what can be replicated, and under what circumstances.
I am using Sybase ASE 12.5. My question is when creating a database, why it is necessary to use master database. What does it mean.
use master
create database student
drop student
use pubs2
The master database is similar to the idea of the root drive in *nix, or the C:\ in windows. It forms the basis of the installation. Using this analogy, the command use is equivalent to changing directories (cd).
By useing the database, you are explicitly telling the software which data structures you are trying to reference, so if you select data from a table, it will look for that table in your current location.
The master database contains all the information for all databases, devices, logins, configurations and more. Because of this you must be in the master database to create new databases.
In practice, unless you are creating or dropping databases, devices, logins, or making other system wide changes, you will not actually use master that frequently.
I am using vb5 and sybase db. I have different roles of people ( with active directory groups), change the tables. I want to write an audit trail (audit table) for this table, to see...all those who changed with time stamp). How to acheive this?
Triggers will work, but depending on the level of granularity and security you need, you may also want to look at using the auditing functionality included in Sybase ASE.
Here is the information on the built in auditing options:
Sybase ASE System Admin Guide: Security Administration - Auditing
Sybase ASE System Admin Guide: Auditing
Try the following:
Create a new table with _log (by copying the original table) with an
extra column called audit and force inserts/updates into the table
with a trigger or by writing an audit procedure. We applied the same
logic to dozens of tables in my last company and it served the
purpose.
I have two databases A and B in same SQL Server instance.. I need to write a trigger -- After update of a table in database B it will fetch data from few tables of database A and then insert data in some table of database B .. The issue is the user who will be accessing the database B does not have access to database A .. If I write a trigger with 'sa' account, will it work when the user inserts some data in database B? Also let me know the scenario what would I have to do if database A is in a different SQL Server?
It can work, but you have to do a few things to get there. Here's the easiest way (though not necessarily the best):
Set the owners of both Databases to 'sa'.
Turn on CROSS-DATABASE chaining for both databases.
Turn on TRUSTWORTHY for the source database (B).
Edit the Trigger and add WITH EXECUTE AS OWNER before the FOR clause.
Note that while this works, it has significant security considerations (particularly #2 and #3). Here is a link that explains this and some other methods and some of the security issues: http://msdn.microsoft.com/en-us/library/ms188304.aspx
if some one delete any object from my database like table,view,sp etc then how can get those detail like who delete and when delete from transaction log. is it possible. please tell me easy way to read transaction log as a result i can get those detail properly.
thanks
No, ransaction log was created for different purposes. There are some product different vendors which is trying to get information from transaction log, but it is not right way.
who delete and when delete
If you need this information you need to create triggers to table for delete or update and collect this information.
If you use MS SQL 2008 you can use Change Data Capture feature.
Apparently you could use a third part product such as Apex SQL Log, although personally I have not used it.
Dependant on how recent the incident occured, you may also be able to extract the information you require from the built in reports in SQL Server 2005 such as the Schema Changes History Report. This information is accessable to you via means of the Default Trace. See using the Default Trace for details.
What you really need to take away from your incident is to use the lesson to devise a schema audit strategy for your environment. There are plenty of articles on the internet that detail how this can be achieved using Triggers. For example see Using DDL Triggers in SQL Server 2005 to Capture Schema Changes
You can restore the database (without overwriting it!) from a full backup / transaction log backup and then copy the deleted objects from there. It's good practice to save the source code for your stored procedures, views and tables outside the database, usually in a source control system, so you don't have to restore database backup to get them.
You can use either DDL triggers or The SQL Server Audit feature
DDL triggers fire on CREATE, ALTER, DROP, and operations related to database object security settings (e.g. GRANT, DENY…)
In the following example, a DDL trigger tracks the CREATE, ALTER, and DROP operations executed on database tables, stored procedures, functions, and views. The trigger example uses a previously created repository table (DDL_Events_by_DDL_TRIGGER) with appropriate rows
CREATE TRIGGER DDL_TRIGGER ON DATABASE
FOR CREATE_TABLE ,
ALTER_TABLE ,
DROP_TABLE ,
CREATE_PROCEDURE ,
ALTER_PROCEDURE ,
DROP_PROCEDURE ,
CREATE_FUNCTION ,
ALTER_FUNCTION ,
DROP_FUNCTION ,
CREATE_VIEW ,
ALTER_VIEW ,
DROP_VIEW
AS
DECLARE
#event xml;
SET
#event = EVENTDATA();
INSERT INTO DDL_Events_by_DDL_TRIGGER
VALUES
(
REPLACE(CONVERT(varchar(58),
#event.query('data(/EVENT_INSTANCE/PostTime)')), 'T', ' ')
,
CONVERT(varchar(185),
#event.query('data(/EVENT_INSTANCE/LoginName)'))
,
CONVERT(varchar(185),
#event.query('data(/EVENT_INSTANCE/DatabaseName)'))
,
CONVERT(varchar(185),
#event.query('data(/EVENT_INSTANCE/SchemaName)'))
,
CONVERT(varchar(185),
#event.query('data(/EVENT_INSTANCE/ObjectName)'))
,
CONVERT(varchar(185),
#event.query('data(/EVENT_INSTANCE/ObjectType)'))
,
CONVERT(varchar(max),
#event.query('data(/EVENT_INSTANCE/TSQLCommand/CommandText)'))
);
The repository table will contain (as specified in the trigger) DDL operations on the database schema, along with information about who, when, and what was altered
Another native method that can be used to determine whether a SQL Server database has been altered is the SQL Server Audit feature. The feature was introduced in SQL Server 2008 and it collects both server and database level actions raised by the SQL Server Extended Events feature. However, the database level action groups are available in SQL Server Enterprise and Developer editions only