Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
magictech
Starting Member
44 Posts |
Posted - 2005-03-09 : 09:35:21
|
| The distributor Agent in one of my replication setup has stop with the following error message "Cannot insert a non-null value into a timestamp column. Use INSERT with a column list or with a default of NULL for the timestamp column."If I restart the Distribution agent, it would try to connect and then it would fail again with the same error message. What is the appropriate way to resolve this type of error message? I would like to maybe flush the problem transaction out of the system so replication could keep working. In the past I've had to rebuild replication in order for the distributor agent to start again. I can’t afford to rebuild replication in production just to resolve this type of error messages. Please any input would be greatly appreciated.Regards |
|
|
jen
Master Smack Fu Yak Hacker
4110 Posts |
Posted - 2005-03-09 : 21:35:40
|
quote: Originally posted by magictech The distributor Agent in one of my replication setup has stop with the following error message "Cannot insert a non-null value into a timestamp column. Use INSERT with a column list or with a default of NULL for the timestamp column."Regards
you have a timestamp column in your article (source table) and an insert is made with a value to this column (sql supplies this value not user)--------------------keeping it simple... |
 |
|
|
magictech
Starting Member
44 Posts |
Posted - 2005-03-10 : 09:15:23
|
| Thanks for responding. I think what you said makes sense. Is there a way to flush out this problem transaction from replication? Currently, the distributor Agent has stop with a red sign on it. I would like to get rid of the error message on the distributor Agent before doing anything else by maybe flushing out the problem transaction from replication. Please any information would be greatly appreciated.Thanks |
 |
|
|
jen
Master Smack Fu Yak Hacker
4110 Posts |
Posted - 2005-03-10 : 22:46:58
|
This is not your problem, it is only a symptom of the real problem.you need to delete the transaction from the article (source table)then you can start replication againmy guess is that this problem is because users can directly insert rows and update columns directly on the base table, or if ever SPs and UDFs are in place, sql injection is allowed.you need to control user inputs --------------------keeping it simple... |
 |
|
|
magictech
Starting Member
44 Posts |
Posted - 2005-03-11 : 09:35:12
|
| Thanks for responding. Once again, I like your answer. You seem to be very knowledgeable with this replication stuff. Thanks again. |
 |
|
|
jen
Master Smack Fu Yak Hacker
4110 Posts |
Posted - 2005-03-13 : 21:27:57
|
quote: Originally posted by magictech Thanks for responding. Once again, I like your answer. You seem to be very knowledgeable with this replication stuff. Thanks again.
YW, i learned the hard way. had to battle with programmers, users, net admins to keep things as stable as they are now. --------------------keeping it simple... |
 |
|
|
|
|
|