Showing posts with label schema. Show all posts
Showing posts with label schema. Show all posts

Friday, March 9, 2012

Error in Merge replication "The schema script..."

I'm trying to set up a merge replication. Publication is created successfully and snapshot also, but when I create pull subscription on subscriber server and merge agent starts, after some time I get an error message of this type:

The schema script '\\ANIL\REPLDATA\unc\ANIL_BEJK_BEJK\20070625142735\dl_HF_vMSCene_3836.sch' could not be propagated to the subscriber.

It seams there is a problem with certain Views and SPs, because tables are successfully created, and some Views and SPs also.

I tried to exclude problematic articles, but every time another one pops up. Up until now, I excluded 7 articles from publication (1 Stored Procedure and 6 Views) but I still get errors.

I gave up because I can't exclude half of the Views and SPs just to make it work.

Is there something that can be done to solve this problem?

Thanks!
Does your SQL Server agent account have rights to read the share \\anil\repldata? Ensure that this account also has rights to list files and folders on the physical drive underlying \\anil\repldata.

If you are using a push subscription it should be the SQL Server agent account on the publisher. If you are using a pull subscription is should be the SQL Server agent account on the subscriber.|||

Hi Hilary

Sharing permisions were set to Read/Write to "Everyone", and security permisions also Read/Write to "Everyone", but it didn't work until I added an account on subscriber computer (which is not in domain) with same username and password as one that exists on publisher (which is in domain). I set SQL Server Agent to use that account and everything started to work fine.

I'm connecting to publisher using the VPN, and despite the fact that those two accounts are not from the same domain, everything is working fine. This is a little bit confusing. It looks like domain name doesn't play any role when logging in to shared folder.

Thanks for the help.

Anil

Error in Merge replication "The schema script..."

I'm trying to set up a merge replication. Publication is created successfully and snapshot also, but when I create pull subscription on subscriber server and merge agent starts, after some time I get an error message of this type:

The schema script '\\ANIL\REPLDATA\unc\ANIL_BEJK_BEJK\20070625142735\dl_HF_vMSCene_3836.sch' could not be propagated to the subscriber.

It seams there is a problem with certain Views and SPs, because tables are successfully created, and some Views and SPs also.

I tried to exclude problematic articles, but every time another one pops up. Up until now, I excluded 7 articles from publication (1 Stored Procedure and 6 Views) but I still get errors.

I gave up because I can't exclude half of the Views and SPs just to make it work.

Is there something that can be done to solve this problem?

Thanks!
Does your SQL Server agent account have rights to read the share \\anil\repldata? Ensure that this account also has rights to list files and folders on the physical drive underlying \\anil\repldata.

If you are using a push subscription it should be the SQL Server agent account on the publisher. If you are using a pull subscription is should be the SQL Server agent account on the subscriber.|||

Hi Hilary

Sharing permisions were set to Read/Write to "Everyone", and security permisions also Read/Write to "Everyone", but it didn't work until I added an account on subscriber computer (which is not in domain) with same username and password as one that exists on publisher (which is in domain). I set SQL Server Agent to use that account and everything started to work fine.

I'm connecting to publisher using the VPN, and despite the fact that those two accounts are not from the same domain, everything is working fine. This is a little bit confusing. It looks like domain name doesn't play any role when logging in to shared folder.

Thanks for the help.

Anil

Sunday, February 26, 2012

Error in datetime validation

xml including a datetime attribute is failing to validate against a simple schema held in an XML schema collection

The same xml validates correctly against the same schema in .Net

Is this a bug? (same behaviour is seen with dates)

Repro follows:

CREATE XML SCHEMA COLLECTION MyCollection AS '
<xs:schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://ns" xmlns:ns="http://ns" xmlns:xs="http://www.w3.org/2001/XMLSchema" version="1.0">
<xs:complexType name="TestType">
<xs:attribute name="id" type="xs:string" use="required"> </xs:attribute>
<xs:attribute name="startDate" type="xs:dateTime" ></xs:attribute>
</xs:complexType>
<xs:element name="TestList" type="ns:TestType">
</xs:element>
</xs:schema>';
go
declare @.xmlvar xml(MyCollection)
set @.xmlvar=
'<TestList xmlns="http://ns" id="D882BA19-81FA-4F99-845D-D8AE57BD0699" startDate="2006-01-02T00:00:00" ></TestList>'


Msg 6926, Level 16, State 1, Line 2
XML Validation: Invalid simple type value: '2006-01-02T00:00:00'. Location: /*:TestList[1]/@.*:startDate

I have just found that the SQL implementation of XML requires the time zone - e.g. 'Z' suffix - but that the .Net implementation does not need the zone.

I now no longer have a problem as I will use the Z suffix - but it would be useful to know whether system.xml or SQL2005 are currently exhibiting the intended behaviour (assuming a target of consistency between the two)

|||

Your observation is correct that the server's schema processor requires the timezone specification - it normalizes the value to UTC and does not preserve the timezone.

The server uses its own XML schema validator, which is different from those in System.Xml and MSXML. As such, any server-side error is generated bu the server's XML schema processor. To isolate whether the error is given by the client or the server, invoke the validation at the server.

Hope this helps.

Thank you,

Shankar

Program Manager

Microsoft SQL Server

|||

Thanks Shankar - As I said in my last post, this is not a problem for me now. However, this is the second time that I have encountered tighter validation in the SQL engine than in system.xml (Previous thread was "XML Schema extension behaving differently between SQL2005 and VB.Net 2.0 ")

This can cause problems when developers do early development and testing saving to XML files. It means that when database integration takes place a different set of problems can occur - which would be completely avoidable if the validation was consistent between system.xml and the SQL engine.

Is there a goal to achieve consistency soon?

If not then it would certainly be useful to have sight of the known differences - I understand from Denis Ruckebusch in the previous thread that a list is being compiled

Thanks

|||

We are looking at relaxing some of the implementation restrictions in the server side validation based on feedback like yours and by removing some of the obstacles that required us to introduce the restrictions in the first place.

Best regards

Michael

|||

Hi Michael

That's encouraging - but for current development it would be very useful to have visibility of the known list of differences

Thanks

Wednesday, February 15, 2012

error handling and logging within a trigger - how much of this would work / would be

Hi,
a little bit of background info; the T-SQL I'm writing is against a
proprietary database schema, I have triggers which are being called
upon through events in a client application over which I have no
control and the schema can change because of patches/new functionality
The pseudo code below is a collation of things I'm contemplating on
doing in my code. The reason being that I want to provide our
application specialists with the possibility to determine what went
wrong where in our production environment, if and when it does, and the
possibility to test patches / new functionality of the properiaty
system by testing in the user interface against a copy of the
production database.
I'd appreciate any feedback on how much of this pseudo code would work
/ would be required?
create trigger trInserrorHandlingInTrigger on propTable for insert as
declare @.returnStatus int, @.aVar int, @.err int
if @.@.rowcount = 0 return
if @.@.rowcount > 1 return
set @.aVar = (select aVal from aTable)
insert into logTable (Nme, sqlStm, aBool, Val) values
('trInserrorHandlingInTrigger', '', 1, @.aVar)
if @.aVar is null return
save transaction lastResort
EXEC @.returnStatus = sp_1_InsertRecords @.aVar = @.aVar
EXEC @.returnStatus = sp_2_InsertRecordsOrRollbackSpOne @.aVar = @.aVar,
@.returnStatus = @.returnStatus
EXEC @.returnStatus = sp_3_UpdateRecordsOrRollback @.aVar = @.aVar,
@.returnStatus = @.returnStatus
select @.err = @.@.error
if @.err <> 0 rollback transaction lastResort
if @.returnStatus <> 0 rollback transaction lastResort
commit transaction
go
create procedure sp_1_InsertRecords
@.aVar int
as
declare
@.err int
insert into wTable (aVal) values (@.aVar)
select @.err = @.@.error
if @.err <> 0
begin
insert into logTable (Nme, sqlStm, aBool, Val) values
('sp_2_InsertRecordsOrRollbackSpOne','lb
l One', 0, @.aVar)
return 1
end
else insert into logTable (Nme, sqlStm, aBool, Val) values
('sp_2_InsertRecordsOrRollbackSpOne','lb
l One', 1, @.aVar)
go
create procedure sp_2_InsertRecordsOrRollbackSpOne
@.aVar int, @.returnStatus int
as
declare
@.err int
if @.returnStatus = 0
begin
-- lbl One
insert into xTable (aVal) values (@.aVar)
select @.err = @.@.error
if @.err <> 0
begin
insert into logTable (Nme, sqlStm, aBool, Val) values
('sp_2_InsertRecordsOrRollbackSpOne','lb
l One', 0, @.aVar)
return 1
end
else insert into logTable (Nme, sqlStm, aBool, Val) values
('sp_2_InsertRecordsOrRollbackSpOne','lb
l One', 1, @.aVar)
end
else
-- lbl Two
delete from wTable where aVal = @.aVar
select @.err = @.@.error
if @.err <> 0
begin
insert into logTable (Nme, sqlStm, aBool, Val) values
('sp_2_InsertRecordsOrRollbackSpOne','lb
l Two', 0, @.aVar)
return 1
end
else insert into logTable (Nme, sqlStm, aBool, Val) values
('sp_2_InsertRecordsOrRollbackSpOne','lb
l Two', 1, @.aVar)
go
create procedure sp_3_UpdateRecordsOrRollback
@.aVar int, @.returnStatus int
as
declare
@.err int
if @.returnStatus = 0
begin
-- lbl One
update yTable set aVal = @.aVar
select @.err = @.@.error
if @.err <> 0
begin
insert into logTable (Nme, sqlStm, aBool, Val) values
('sp_3_UpdateRecordsOrRollback','lbl One', 0, @.aVar)
return 1
end
else insert into logTable (Nme, sqlStm, aBool, Val) values
('sp_3_UpdateRecordsOrRollback','lbl One', 1, @.aVar)
end
else
-- lbl Two
delete from aTable where aVal = @.aVar
select @.err = @.@.error
if @.err <> 0
begin
insert into logTable (Nme, sqlStm, aBool, Val) values
('sp_3_UpdateRecordsOrRollback','lbl Two', 0, @.aVar)
return 1
end
else insert into logTable (Nme, sqlStm, aBool, Val) values
('sp_3_UpdateRecordsOrRollback','lbl Two', 1, @.aVar)
-- lbl Three
delete from wTable where aVal = @.aVar
select @.err = @.@.error
if @.err <> 0
begin
insert into logTable (Nme, sqlStm, aBool, Val) values
('sp_3_UpdateRecordsOrRollback', 'lbl Three', 0, @.aVar)
return 1
end
else insert into logTable (Nme, sqlStm, aBool, Val) values
('sp_3_UpdateRecordsOrRollback','lbl Three', 1, @.aVar)
go
regards,
GerardGerard (g.doeswijk@.gmail.com) writes:
> create trigger trInserrorHandlingInTrigger on propTable for insert as
> declare @.returnStatus int, @.aVar int, @.err int
>
> if @.@.rowcount = 0 return
> if @.@.rowcount > 1 return
> set @.aVar = (select aVal from aTable)
Would be from inserted, not just any table.

> save transaction lastResort
> EXEC @.returnStatus = sp_1_InsertRecords @.aVar = @.aVar
> EXEC @.returnStatus = sp_2_InsertRecordsOrRollbackSpOne @.aVar = @.aVar,
> @.returnStatus = @.returnStatus
> EXEC @.returnStatus = sp_3_UpdateRecordsOrRollback @.aVar = @.aVar,
> @.returnStatus = @.returnStatus
>
> select @.err = @.@.error
> if @.err <> 0 rollback transaction lastResort
> if @.returnStatus <> 0 rollback transaction lastResort
>
> commit transaction
First, the sp_ prefix is reserved for system procedures, don't use it
for your own code. There could be nasty surprises.
This appears to be a bit overkill. And flat out wrong as for the COMMIT
part.
This is the scoop: if an error occurs when you are in a trigger, including
a stored procedure called by a trigger, the entire batch is aborted, and
the current transaction is rolled back. So this savepoint thing is not
likely to work.
And what's wrong with the COMMIT? If a trigger exits with a lower trancount
that it was entered with, that too aborts the batch, and rolls back any
transaction. The idea is that a rollback in a trigger should roll back
the batch, but if you COMMIT the same thing happens.|||Thanks for the feedback, BOL was not particularly clear for me on the
SAVE TRAN and COMMIT PART. I had sort of thought that there was some
possibility to persist some data outside the scope of the trigger by
giving this commit. I think we just have to start living with the idea
in any case.