I just spent 4 hours of frustration, trying to debug a problem with SQL
2000. It was self-inflicted, as it turned out, but I could have fixed
the problem in 5 minutes instead of 4 hours if the @.#%@.#$% error
message:
"String or binary data would be truncated"
would give some CLUES! How about a field name, or even the data that
it's trying to put into the mystery field in some mystery table? And
why not tell me whether it's actually a string or binary data, not
lumping them both together. (I envision a mythical error message that
says "You have caused a numeric overflow, or underflow, or divide by
zero, or there's a key violation, or a trigger is not defined, or the
statement syntax is wrong." Which might be a perfectly correct but not-
helpful error message.)
I was convinced that I was trying to put a single character 'C' into a
field defined as Char(2), and I was tearing my hair out. Aaargh.
The actual Update statement was buried in the guts of a DTS transform,
but this isn't a DTS complaint, it's a SQL error message complaint.
When you try to put a null into a field that can't accept nulls, at
least the error message gives you the name of the field that you're
trying to update. That is infinitely more helpful than this stupid
truncation message. (And I don't want to turn warnings off; in this
case, I was trying to put the wrong value into a different field, so the
error was important -- but I wasn't being pointed to the right place.)
A little help from the error message would be nice.
Hmmm. I wonder if the new upcoming SQL does a better job. I'll have to
ask someone over there.
David Walker
YOu sure have to give us some mistery SQL Query or magic DDL to understand
whats going on, seems that one column is truncated.
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
"DWalker" <none@.none.com> schrieb im Newsbeitrag
news:OUBF6SnSFHA.3356@.TK2MSFTNGP12.phx.gbl...
>I just spent 4 hours of frustration, trying to debug a problem with SQL
> 2000. It was self-inflicted, as it turned out, but I could have fixed
> the problem in 5 minutes instead of 4 hours if the @.#%@.#$% error
> message:
> "String or binary data would be truncated"
> would give some CLUES! How about a field name, or even the data that
> it's trying to put into the mystery field in some mystery table? And
> why not tell me whether it's actually a string or binary data, not
> lumping them both together. (I envision a mythical error message that
> says "You have caused a numeric overflow, or underflow, or divide by
> zero, or there's a key violation, or a trigger is not defined, or the
> statement syntax is wrong." Which might be a perfectly correct but not-
> helpful error message.)
> I was convinced that I was trying to put a single character 'C' into a
> field defined as Char(2), and I was tearing my hair out. Aaargh.
> The actual Update statement was buried in the guts of a DTS transform,
> but this isn't a DTS complaint, it's a SQL error message complaint.
> When you try to put a null into a field that can't accept nulls, at
> least the error message gives you the name of the field that you're
> trying to update. That is infinitely more helpful than this stupid
> truncation message. (And I don't want to turn warnings off; in this
> case, I was trying to put the wrong value into a different field, so the
> error was important -- but I wasn't being pointed to the right place.)
> A little help from the error message would be nice.
> Hmmm. I wonder if the new upcoming SQL does a better job. I'll have to
> ask someone over there.
>
> David Walker
|||David,
I agree that error less-informative messages as a pain to work with. Did you consider posting to
sqlwish@.microsoft.com on this case?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
|||I figured out my problem, the complaint is that the error message is not
very helpful. I was not looking for more assistance, I was just
complaining about the error message... But thanks!
David
"Jens Smeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote
in news:#QWpPWnSFHA.1312@.TK2MSFTNGP14.phx.gbl:
> YOu sure have to give us some mistery SQL Query or magic DDL to
> understand whats going on, seems that one column is truncated.
> HTH, Jens Suessmeyer.
> --
> http://www.sqlserver2005.de
> --
> "DWalker" <none@.none.com> schrieb im Newsbeitrag
> news:OUBF6SnSFHA.3356@.TK2MSFTNGP12.phx.gbl...
>
|||"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in news:uzUDsVnSFHA.3712@.TK2MSFTNGP10.phx.gbl:
> David,
> I agree that error less-informative messages as a pain to work with.
> Did you consider posting to sqlwish@.microsoft.com on this case?
>
I will do that, thanks.
David
|||ok. Gotit. :-)
"DWalker" <none@.none.com> schrieb im Newsbeitrag
news:O763lynSFHA.3176@.TK2MSFTNGP09.phx.gbl...
>I figured out my problem, the complaint is that the error message is not
> very helpful. I was not looking for more assistance, I was just
> complaining about the error message... But thanks!
> David
>
> "Jens Smeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote
> in news:#QWpPWnSFHA.1312@.TK2MSFTNGP14.phx.gbl:
>
Showing posts with label spent. Show all posts
Showing posts with label spent. Show all posts
Sunday, March 11, 2012
Bad error message
I just spent 4 hours of frustration, trying to debug a problem with SQL
2000. It was self-inflicted, as it turned out, but I could have fixed
the problem in 5 minutes instead of 4 hours if the @.#%@.#$% error
message:
"String or binary data would be truncated"
would give some CLUES! How about a field name, or even the data that
it's trying to put into the mystery field in some mystery table? And
why not tell me whether it's actually a string or binary data, not
lumping them both together. (I envision a mythical error message that
says "You have caused a numeric overflow, or underflow, or divide by
zero, or there's a key violation, or a trigger is not defined, or the
statement syntax is wrong." Which might be a perfectly correct but not-
helpful error message.)
I was convinced that I was trying to put a single character 'C' into a
field defined as Char(2), and I was tearing my hair out. Aaargh.
The actual Update statement was buried in the guts of a DTS transform,
but this isn't a DTS complaint, it's a SQL error message complaint.
When you try to put a null into a field that can't accept nulls, at
least the error message gives you the name of the field that you're
trying to update. That is infinitely more helpful than this stupid
truncation message. (And I don't want to turn warnings off; in this
case, I was trying to put the wrong value into a different field, so the
error was important -- but I wasn't being pointed to the right place.)
A little help from the error message would be nice.
Hmmm. I wonder if the new upcoming SQL does a better job. I'll have to
ask someone over there.
David WalkerYOu sure have to give us some mistery SQL Query or magic DDL to understand
whats going on, seems that one column is truncated.
HTH, Jens Suessmeyer.
--
http://www.sqlserver2005.de
--
"DWalker" <none@.none.com> schrieb im Newsbeitrag
news:OUBF6SnSFHA.3356@.TK2MSFTNGP12.phx.gbl...
>I just spent 4 hours of frustration, trying to debug a problem with SQL
> 2000. It was self-inflicted, as it turned out, but I could have fixed
> the problem in 5 minutes instead of 4 hours if the @.#%@.#$% error
> message:
> "String or binary data would be truncated"
> would give some CLUES! How about a field name, or even the data that
> it's trying to put into the mystery field in some mystery table? And
> why not tell me whether it's actually a string or binary data, not
> lumping them both together. (I envision a mythical error message that
> says "You have caused a numeric overflow, or underflow, or divide by
> zero, or there's a key violation, or a trigger is not defined, or the
> statement syntax is wrong." Which might be a perfectly correct but not-
> helpful error message.)
> I was convinced that I was trying to put a single character 'C' into a
> field defined as Char(2), and I was tearing my hair out. Aaargh.
> The actual Update statement was buried in the guts of a DTS transform,
> but this isn't a DTS complaint, it's a SQL error message complaint.
> When you try to put a null into a field that can't accept nulls, at
> least the error message gives you the name of the field that you're
> trying to update. That is infinitely more helpful than this stupid
> truncation message. (And I don't want to turn warnings off; in this
> case, I was trying to put the wrong value into a different field, so the
> error was important -- but I wasn't being pointed to the right place.)
> A little help from the error message would be nice.
> Hmmm. I wonder if the new upcoming SQL does a better job. I'll have to
> ask someone over there.
>
> David Walker|||David,
I agree that error less-informative messages as a pain to work with. Did you consider posting to
sqlwish@.microsoft.com on this case?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/|||I figured out my problem, the complaint is that the error message is not
very helpful. I was not looking for more assistance, I was just
complaining about the error message... But thanks!
David
"Jens Süßmeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote
in news:#QWpPWnSFHA.1312@.TK2MSFTNGP14.phx.gbl:
> YOu sure have to give us some mistery SQL Query or magic DDL to
> understand whats going on, seems that one column is truncated.
> HTH, Jens Suessmeyer.
> --
> http://www.sqlserver2005.de
> --
> "DWalker" <none@.none.com> schrieb im Newsbeitrag
> news:OUBF6SnSFHA.3356@.TK2MSFTNGP12.phx.gbl...
>>I just spent 4 hours of frustration, trying to debug a problem with
>>SQL
>> 2000. It was self-inflicted, as it turned out, but I could have
>> fixed the problem in 5 minutes instead of 4 hours if the @.#%@.#$%
>> error message:
>> "String or binary data would be truncated"
>> would give some CLUES! How about a field name, or even the data that
>> it's trying to put into the mystery field in some mystery table? And
>> why not tell me whether it's actually a string or binary data, not
>> lumping them both together. (I envision a mythical error message
>> that says "You have caused a numeric overflow, or underflow, or
>> divide by zero, or there's a key violation, or a trigger is not
>> defined, or the statement syntax is wrong." Which might be a
>> perfectly correct but not- helpful error message.)
>> I was convinced that I was trying to put a single character 'C' into
>> a field defined as Char(2), and I was tearing my hair out. Aaargh.
>> The actual Update statement was buried in the guts of a DTS
>> transform, but this isn't a DTS complaint, it's a SQL error message
>> complaint.
>> When you try to put a null into a field that can't accept nulls, at
>> least the error message gives you the name of the field that you're
>> trying to update. That is infinitely more helpful than this stupid
>> truncation message. (And I don't want to turn warnings off; in this
>> case, I was trying to put the wrong value into a different field, so
>> the error was important -- but I wasn't being pointed to the right
>> place.)
>> A little help from the error message would be nice.
>> Hmmm. I wonder if the new upcoming SQL does a better job. I'll have
>> to ask someone over there.
>>
>> David Walker
>|||"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in news:uzUDsVnSFHA.3712@.TK2MSFTNGP10.phx.gbl:
> David,
> I agree that error less-informative messages as a pain to work with.
> Did you consider posting to sqlwish@.microsoft.com on this case?
>
I will do that, thanks.
David|||ok. Gotit. :-)
"DWalker" <none@.none.com> schrieb im Newsbeitrag
news:O763lynSFHA.3176@.TK2MSFTNGP09.phx.gbl...
>I figured out my problem, the complaint is that the error message is not
> very helpful. I was not looking for more assistance, I was just
> complaining about the error message... But thanks!
> David
>
> "Jens Süßmeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote
> in news:#QWpPWnSFHA.1312@.TK2MSFTNGP14.phx.gbl:
>> YOu sure have to give us some mistery SQL Query or magic DDL to
>> understand whats going on, seems that one column is truncated.
>> HTH, Jens Suessmeyer.
>> --
>> http://www.sqlserver2005.de
>> --
>> "DWalker" <none@.none.com> schrieb im Newsbeitrag
>> news:OUBF6SnSFHA.3356@.TK2MSFTNGP12.phx.gbl...
>>I just spent 4 hours of frustration, trying to debug a problem with
>>SQL
>> 2000. It was self-inflicted, as it turned out, but I could have
>> fixed the problem in 5 minutes instead of 4 hours if the @.#%@.#$%
>> error message:
>> "String or binary data would be truncated"
>> would give some CLUES! How about a field name, or even the data that
>> it's trying to put into the mystery field in some mystery table? And
>> why not tell me whether it's actually a string or binary data, not
>> lumping them both together. (I envision a mythical error message
>> that says "You have caused a numeric overflow, or underflow, or
>> divide by zero, or there's a key violation, or a trigger is not
>> defined, or the statement syntax is wrong." Which might be a
>> perfectly correct but not- helpful error message.)
>> I was convinced that I was trying to put a single character 'C' into
>> a field defined as Char(2), and I was tearing my hair out. Aaargh.
>> The actual Update statement was buried in the guts of a DTS
>> transform, but this isn't a DTS complaint, it's a SQL error message
>> complaint.
>> When you try to put a null into a field that can't accept nulls, at
>> least the error message gives you the name of the field that you're
>> trying to update. That is infinitely more helpful than this stupid
>> truncation message. (And I don't want to turn warnings off; in this
>> case, I was trying to put the wrong value into a different field, so
>> the error was important -- but I wasn't being pointed to the right
>> place.)
>> A little help from the error message would be nice.
>> Hmmm. I wonder if the new upcoming SQL does a better job. I'll have
>> to ask someone over there.
>>
>> David Walker
>>
>
2000. It was self-inflicted, as it turned out, but I could have fixed
the problem in 5 minutes instead of 4 hours if the @.#%@.#$% error
message:
"String or binary data would be truncated"
would give some CLUES! How about a field name, or even the data that
it's trying to put into the mystery field in some mystery table? And
why not tell me whether it's actually a string or binary data, not
lumping them both together. (I envision a mythical error message that
says "You have caused a numeric overflow, or underflow, or divide by
zero, or there's a key violation, or a trigger is not defined, or the
statement syntax is wrong." Which might be a perfectly correct but not-
helpful error message.)
I was convinced that I was trying to put a single character 'C' into a
field defined as Char(2), and I was tearing my hair out. Aaargh.
The actual Update statement was buried in the guts of a DTS transform,
but this isn't a DTS complaint, it's a SQL error message complaint.
When you try to put a null into a field that can't accept nulls, at
least the error message gives you the name of the field that you're
trying to update. That is infinitely more helpful than this stupid
truncation message. (And I don't want to turn warnings off; in this
case, I was trying to put the wrong value into a different field, so the
error was important -- but I wasn't being pointed to the right place.)
A little help from the error message would be nice.
Hmmm. I wonder if the new upcoming SQL does a better job. I'll have to
ask someone over there.
David WalkerYOu sure have to give us some mistery SQL Query or magic DDL to understand
whats going on, seems that one column is truncated.
HTH, Jens Suessmeyer.
--
http://www.sqlserver2005.de
--
"DWalker" <none@.none.com> schrieb im Newsbeitrag
news:OUBF6SnSFHA.3356@.TK2MSFTNGP12.phx.gbl...
>I just spent 4 hours of frustration, trying to debug a problem with SQL
> 2000. It was self-inflicted, as it turned out, but I could have fixed
> the problem in 5 minutes instead of 4 hours if the @.#%@.#$% error
> message:
> "String or binary data would be truncated"
> would give some CLUES! How about a field name, or even the data that
> it's trying to put into the mystery field in some mystery table? And
> why not tell me whether it's actually a string or binary data, not
> lumping them both together. (I envision a mythical error message that
> says "You have caused a numeric overflow, or underflow, or divide by
> zero, or there's a key violation, or a trigger is not defined, or the
> statement syntax is wrong." Which might be a perfectly correct but not-
> helpful error message.)
> I was convinced that I was trying to put a single character 'C' into a
> field defined as Char(2), and I was tearing my hair out. Aaargh.
> The actual Update statement was buried in the guts of a DTS transform,
> but this isn't a DTS complaint, it's a SQL error message complaint.
> When you try to put a null into a field that can't accept nulls, at
> least the error message gives you the name of the field that you're
> trying to update. That is infinitely more helpful than this stupid
> truncation message. (And I don't want to turn warnings off; in this
> case, I was trying to put the wrong value into a different field, so the
> error was important -- but I wasn't being pointed to the right place.)
> A little help from the error message would be nice.
> Hmmm. I wonder if the new upcoming SQL does a better job. I'll have to
> ask someone over there.
>
> David Walker|||David,
I agree that error less-informative messages as a pain to work with. Did you consider posting to
sqlwish@.microsoft.com on this case?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/|||I figured out my problem, the complaint is that the error message is not
very helpful. I was not looking for more assistance, I was just
complaining about the error message... But thanks!
David
"Jens Süßmeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote
in news:#QWpPWnSFHA.1312@.TK2MSFTNGP14.phx.gbl:
> YOu sure have to give us some mistery SQL Query or magic DDL to
> understand whats going on, seems that one column is truncated.
> HTH, Jens Suessmeyer.
> --
> http://www.sqlserver2005.de
> --
> "DWalker" <none@.none.com> schrieb im Newsbeitrag
> news:OUBF6SnSFHA.3356@.TK2MSFTNGP12.phx.gbl...
>>I just spent 4 hours of frustration, trying to debug a problem with
>>SQL
>> 2000. It was self-inflicted, as it turned out, but I could have
>> fixed the problem in 5 minutes instead of 4 hours if the @.#%@.#$%
>> error message:
>> "String or binary data would be truncated"
>> would give some CLUES! How about a field name, or even the data that
>> it's trying to put into the mystery field in some mystery table? And
>> why not tell me whether it's actually a string or binary data, not
>> lumping them both together. (I envision a mythical error message
>> that says "You have caused a numeric overflow, or underflow, or
>> divide by zero, or there's a key violation, or a trigger is not
>> defined, or the statement syntax is wrong." Which might be a
>> perfectly correct but not- helpful error message.)
>> I was convinced that I was trying to put a single character 'C' into
>> a field defined as Char(2), and I was tearing my hair out. Aaargh.
>> The actual Update statement was buried in the guts of a DTS
>> transform, but this isn't a DTS complaint, it's a SQL error message
>> complaint.
>> When you try to put a null into a field that can't accept nulls, at
>> least the error message gives you the name of the field that you're
>> trying to update. That is infinitely more helpful than this stupid
>> truncation message. (And I don't want to turn warnings off; in this
>> case, I was trying to put the wrong value into a different field, so
>> the error was important -- but I wasn't being pointed to the right
>> place.)
>> A little help from the error message would be nice.
>> Hmmm. I wonder if the new upcoming SQL does a better job. I'll have
>> to ask someone over there.
>>
>> David Walker
>|||"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in news:uzUDsVnSFHA.3712@.TK2MSFTNGP10.phx.gbl:
> David,
> I agree that error less-informative messages as a pain to work with.
> Did you consider posting to sqlwish@.microsoft.com on this case?
>
I will do that, thanks.
David|||ok. Gotit. :-)
"DWalker" <none@.none.com> schrieb im Newsbeitrag
news:O763lynSFHA.3176@.TK2MSFTNGP09.phx.gbl...
>I figured out my problem, the complaint is that the error message is not
> very helpful. I was not looking for more assistance, I was just
> complaining about the error message... But thanks!
> David
>
> "Jens Süßmeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote
> in news:#QWpPWnSFHA.1312@.TK2MSFTNGP14.phx.gbl:
>> YOu sure have to give us some mistery SQL Query or magic DDL to
>> understand whats going on, seems that one column is truncated.
>> HTH, Jens Suessmeyer.
>> --
>> http://www.sqlserver2005.de
>> --
>> "DWalker" <none@.none.com> schrieb im Newsbeitrag
>> news:OUBF6SnSFHA.3356@.TK2MSFTNGP12.phx.gbl...
>>I just spent 4 hours of frustration, trying to debug a problem with
>>SQL
>> 2000. It was self-inflicted, as it turned out, but I could have
>> fixed the problem in 5 minutes instead of 4 hours if the @.#%@.#$%
>> error message:
>> "String or binary data would be truncated"
>> would give some CLUES! How about a field name, or even the data that
>> it's trying to put into the mystery field in some mystery table? And
>> why not tell me whether it's actually a string or binary data, not
>> lumping them both together. (I envision a mythical error message
>> that says "You have caused a numeric overflow, or underflow, or
>> divide by zero, or there's a key violation, or a trigger is not
>> defined, or the statement syntax is wrong." Which might be a
>> perfectly correct but not- helpful error message.)
>> I was convinced that I was trying to put a single character 'C' into
>> a field defined as Char(2), and I was tearing my hair out. Aaargh.
>> The actual Update statement was buried in the guts of a DTS
>> transform, but this isn't a DTS complaint, it's a SQL error message
>> complaint.
>> When you try to put a null into a field that can't accept nulls, at
>> least the error message gives you the name of the field that you're
>> trying to update. That is infinitely more helpful than this stupid
>> truncation message. (And I don't want to turn warnings off; in this
>> case, I was trying to put the wrong value into a different field, so
>> the error was important -- but I wasn't being pointed to the right
>> place.)
>> A little help from the error message would be nice.
>> Hmmm. I wonder if the new upcoming SQL does a better job. I'll have
>> to ask someone over there.
>>
>> David Walker
>>
>
Bad error message
I just spent 4 hours of frustration, trying to debug a problem with SQL
2000. It was self-inflicted, as it turned out, but I could have fixed
the problem in 5 minutes instead of 4 hours if the @.#%@.#$% error
message:
"String or binary data would be truncated"
would give some CLUES! How about a field name, or even the data that
it's trying to put into the mystery field in some mystery table? And
why not tell me whether it's actually a string or binary data, not
lumping them both together. (I envision a mythical error message that
says "You have caused a numeric overflow, or underflow, or divide by
zero, or there's a key violation, or a trigger is not defined, or the
statement syntax is wrong." Which might be a perfectly correct but not-
helpful error message.)
I was convinced that I was trying to put a single character 'C' into a
field defined as Char(2), and I was tearing my hair out. Aaargh.
The actual Update statement was buried in the guts of a DTS transform,
but this isn't a DTS complaint, it's a SQL error message complaint.
When you try to put a null into a field that can't accept nulls, at
least the error message gives you the name of the field that you're
trying to update. That is infinitely more helpful than this stupid
truncation message. (And I don't want to turn warnings off; in this
case, I was trying to put the wrong value into a different field, so the
error was important -- but I wasn't being pointed to the right place.)
A little help from the error message would be nice.
Hmmm. I wonder if the new upcoming SQL does a better job. I'll have to
ask someone over there.
David WalkerYOu sure have to give us some mistery SQL Query or magic DDL to understand
whats going on, seems that one column is truncated.
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
--
"DWalker" <none@.none.com> schrieb im Newsbeitrag
news:OUBF6SnSFHA.3356@.TK2MSFTNGP12.phx.gbl...
>I just spent 4 hours of frustration, trying to debug a problem with SQL
> 2000. It was self-inflicted, as it turned out, but I could have fixed
> the problem in 5 minutes instead of 4 hours if the @.#%@.#$% error
> message:
> "String or binary data would be truncated"
> would give some CLUES! How about a field name, or even the data that
> it's trying to put into the mystery field in some mystery table? And
> why not tell me whether it's actually a string or binary data, not
> lumping them both together. (I envision a mythical error message that
> says "You have caused a numeric overflow, or underflow, or divide by
> zero, or there's a key violation, or a trigger is not defined, or the
> statement syntax is wrong." Which might be a perfectly correct but not-
> helpful error message.)
> I was convinced that I was trying to put a single character 'C' into a
> field defined as Char(2), and I was tearing my hair out. Aaargh.
> The actual Update statement was buried in the guts of a DTS transform,
> but this isn't a DTS complaint, it's a SQL error message complaint.
> When you try to put a null into a field that can't accept nulls, at
> least the error message gives you the name of the field that you're
> trying to update. That is infinitely more helpful than this stupid
> truncation message. (And I don't want to turn warnings off; in this
> case, I was trying to put the wrong value into a different field, so the
> error was important -- but I wasn't being pointed to the right place.)
> A little help from the error message would be nice.
> Hmmm. I wonder if the new upcoming SQL does a better job. I'll have to
> ask someone over there.
>
> David Walker|||David,
I agree that error less-informative messages as a pain to work with. Did you
consider posting to
sqlwish@.microsoft.com on this case?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/|||I figured out my problem, the complaint is that the error message is not
very helpful. I was not looking for more assistance, I was just
complaining about the error message... But thanks!
David
"Jens Smeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote
in news:#QWpPWnSFHA.1312@.TK2MSFTNGP14.phx.gbl:
> YOu sure have to give us some mistery SQL Query or magic DDL to
> understand whats going on, seems that one column is truncated.
> HTH, Jens Suessmeyer.
> --
> http://www.sqlserver2005.de
> --
> "DWalker" <none@.none.com> schrieb im Newsbeitrag
> news:OUBF6SnSFHA.3356@.TK2MSFTNGP12.phx.gbl...
>|||"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in news:uzUDsVnSFHA.3712@.TK2MSFTNGP10.phx.gbl:
> David,
> I agree that error less-informative messages as a pain to work with.
> Did you consider posting to sqlwish@.microsoft.com on this case?
>
I will do that, thanks.
David|||ok. Gotit. :-)
"DWalker" <none@.none.com> schrieb im Newsbeitrag
news:O763lynSFHA.3176@.TK2MSFTNGP09.phx.gbl...
>I figured out my problem, the complaint is that the error message is not
> very helpful. I was not looking for more assistance, I was just
> complaining about the error message... But thanks!
> David
>
> "Jens Smeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote
> in news:#QWpPWnSFHA.1312@.TK2MSFTNGP14.phx.gbl:
>
>
2000. It was self-inflicted, as it turned out, but I could have fixed
the problem in 5 minutes instead of 4 hours if the @.#%@.#$% error
message:
"String or binary data would be truncated"
would give some CLUES! How about a field name, or even the data that
it's trying to put into the mystery field in some mystery table? And
why not tell me whether it's actually a string or binary data, not
lumping them both together. (I envision a mythical error message that
says "You have caused a numeric overflow, or underflow, or divide by
zero, or there's a key violation, or a trigger is not defined, or the
statement syntax is wrong." Which might be a perfectly correct but not-
helpful error message.)
I was convinced that I was trying to put a single character 'C' into a
field defined as Char(2), and I was tearing my hair out. Aaargh.
The actual Update statement was buried in the guts of a DTS transform,
but this isn't a DTS complaint, it's a SQL error message complaint.
When you try to put a null into a field that can't accept nulls, at
least the error message gives you the name of the field that you're
trying to update. That is infinitely more helpful than this stupid
truncation message. (And I don't want to turn warnings off; in this
case, I was trying to put the wrong value into a different field, so the
error was important -- but I wasn't being pointed to the right place.)
A little help from the error message would be nice.
Hmmm. I wonder if the new upcoming SQL does a better job. I'll have to
ask someone over there.
David WalkerYOu sure have to give us some mistery SQL Query or magic DDL to understand
whats going on, seems that one column is truncated.
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
--
"DWalker" <none@.none.com> schrieb im Newsbeitrag
news:OUBF6SnSFHA.3356@.TK2MSFTNGP12.phx.gbl...
>I just spent 4 hours of frustration, trying to debug a problem with SQL
> 2000. It was self-inflicted, as it turned out, but I could have fixed
> the problem in 5 minutes instead of 4 hours if the @.#%@.#$% error
> message:
> "String or binary data would be truncated"
> would give some CLUES! How about a field name, or even the data that
> it's trying to put into the mystery field in some mystery table? And
> why not tell me whether it's actually a string or binary data, not
> lumping them both together. (I envision a mythical error message that
> says "You have caused a numeric overflow, or underflow, or divide by
> zero, or there's a key violation, or a trigger is not defined, or the
> statement syntax is wrong." Which might be a perfectly correct but not-
> helpful error message.)
> I was convinced that I was trying to put a single character 'C' into a
> field defined as Char(2), and I was tearing my hair out. Aaargh.
> The actual Update statement was buried in the guts of a DTS transform,
> but this isn't a DTS complaint, it's a SQL error message complaint.
> When you try to put a null into a field that can't accept nulls, at
> least the error message gives you the name of the field that you're
> trying to update. That is infinitely more helpful than this stupid
> truncation message. (And I don't want to turn warnings off; in this
> case, I was trying to put the wrong value into a different field, so the
> error was important -- but I wasn't being pointed to the right place.)
> A little help from the error message would be nice.
> Hmmm. I wonder if the new upcoming SQL does a better job. I'll have to
> ask someone over there.
>
> David Walker|||David,
I agree that error less-informative messages as a pain to work with. Did you
consider posting to
sqlwish@.microsoft.com on this case?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/|||I figured out my problem, the complaint is that the error message is not
very helpful. I was not looking for more assistance, I was just
complaining about the error message... But thanks!
David
"Jens Smeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote
in news:#QWpPWnSFHA.1312@.TK2MSFTNGP14.phx.gbl:
> YOu sure have to give us some mistery SQL Query or magic DDL to
> understand whats going on, seems that one column is truncated.
> HTH, Jens Suessmeyer.
> --
> http://www.sqlserver2005.de
> --
> "DWalker" <none@.none.com> schrieb im Newsbeitrag
> news:OUBF6SnSFHA.3356@.TK2MSFTNGP12.phx.gbl...
>|||"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in news:uzUDsVnSFHA.3712@.TK2MSFTNGP10.phx.gbl:
> David,
> I agree that error less-informative messages as a pain to work with.
> Did you consider posting to sqlwish@.microsoft.com on this case?
>
I will do that, thanks.
David|||ok. Gotit. :-)
"DWalker" <none@.none.com> schrieb im Newsbeitrag
news:O763lynSFHA.3176@.TK2MSFTNGP09.phx.gbl...
>I figured out my problem, the complaint is that the error message is not
> very helpful. I was not looking for more assistance, I was just
> complaining about the error message... But thanks!
> David
>
> "Jens Smeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote
> in news:#QWpPWnSFHA.1312@.TK2MSFTNGP14.phx.gbl:
>
>
Backward Compatiblity of Management Studio
I'm relatively new to SQL Server. I have spent some time in Enterprise Manager for our SQL Server 2000 instances. We are testing SQL Server 2005, and I found that I was able to register 2000 databases into the new SQL Server 2005 Management Studio.
My question: Why not switch immediately to SQL Server 2005 Management Studio for managing all of our old 2000 instances, as well as the new 2005 instances are they are built/upgraded/migrated?
You can certainly do that, but not everything works. For one thing, the "reports" tab in SSMS won't work against SQL 2K, because 2K doesn't contain any of the dynamic management views to make it work. SSMS also can't edit the DTS packages in SQ, or work with some of the maintance plans.
If all that's OK, by all means go ahead and use it.
Buck Woody
Backward Compatiblity of Management Studio
I'm relatively new to SQL Server. I have spent some time in Enterprise Manager for our SQL Server 2000 instances. We are testing SQL Server 2005, and I found that I was able to register 2000 databases into the new SQL Server 2005 Management Studio.
My question: Why not switch immediately to SQL Server 2005 Management Studio for managing all of our old 2000 instances, as well as the new 2005 instances are they are built/upgraded/migrated?
You can certainly do that, but not everything works. For one thing, the "reports" tab in SSMS won't work against SQL 2K, because 2K doesn't contain any of the dynamic management views to make it work. SSMS also can't edit the DTS packages in SQ, or work with some of the maintance plans.
If all that's OK, by all means go ahead and use it.
Buck Woody
Thursday, February 16, 2012
Backup/copy to remote server
Hello,
I've spent the afternoon reading old newsgroup posts and BOL but am
still a bit confused about the best way to approach a new backup
scheme.
My organization would like to establish a single repository for backups
from our database servers, by either backing up databases on each
server and then moving them to the new, central server in some
automated fashion, or by simply pointing to the remote server as the
backup device.
>From a network performance standpoint I think backing up locally and
then copying the resulting files to a remote destination may be the
better option, as we have several servers and at least one of the
databases residing on them results in an almost 2GB backup file (with
most of the remainder smaller than that). I'm also unsure of exactly
how to go about this.
I believe SQL Server has been installed by default under the local
system account, so I'm wondering if this will limit my options with
regard to authentication across servers.
I've read about the BACKUP command, "log shipping" and other options,
but am not sure if any match our requirements.
If anyone could shine a light down the right path for me, my blood
pressure would be grateful. ;)vast55555@.yahoo.com wrote:
> Hello,
> I've spent the afternoon reading old newsgroup posts and BOL but am
> still a bit confused about the best way to approach a new backup
> scheme.
> My organization would like to establish a single repository for backups
> from our database servers, by either backing up databases on each
> server and then moving them to the new, central server in some
> automated fashion, or by simply pointing to the remote server as the
> backup device.
>
> then copying the resulting files to a remote destination may be the
> better option, as we have several servers and at least one of the
> databases residing on them results in an almost 2GB backup file (with
> most of the remainder smaller than that). I'm also unsure of exactly
> how to go about this.
> I believe SQL Server has been installed by default under the local
> system account, so I'm wondering if this will limit my options with
> regard to authentication across servers.
> I've read about the BACKUP command, "log shipping" and other options,
> but am not sure if any match our requirements.
> If anyone could shine a light down the right path for me, my blood
> pressure would be grateful. ;)
>
Create a share on your central server, configure SQL to run as a domain
user, grant that domain user permissions to the share, then use the
BACKUP command to backup directly to the UNC for that share. We move a
dozen backups around on our network each night, some of which are
approaching 200GB, there is no noticeable difference between backing up
locally and then copying vs. backing up over the network.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Hi Tracy,
Thanks for your quick response. That sounds like the way to go. One
potential problem is that this is a hosted situation--not in-house--and
I think there may be no domain, but rather isolated machines (I'm not a
network engineer by trade so I'm a bit ignorant here).
Tracy McKibben wrote:
> Create a share on your central server, configure SQL to run as a domain
> user, grant that domain user permissions to the share, then use the
> BACKUP command to backup directly to the UNC for that share. We move a
> dozen backups around on our network each night, some of which are
> approaching 200GB, there is no noticeable difference between backing up
> locally and then copying vs. backing up over the network.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||Performance wise, backing up straight to a remote file share is often faster
than backing up locally and then copying the backup file to the same file
share. But there are other factors to consider. For instance, with backing u
p
straight to the remote file share, if it fails towards to the end due to som
e
network issue, the retry may take longer than just retrying the copy
operation.
Linchi
"vast55555@.yahoo.com" wrote:
> Hello,
> I've spent the afternoon reading old newsgroup posts and BOL but am
> still a bit confused about the best way to approach a new backup
> scheme.
> My organization would like to establish a single repository for backups
> from our database servers, by either backing up databases on each
> server and then moving them to the new, central server in some
> automated fashion, or by simply pointing to the remote server as the
> backup device.
>
> then copying the resulting files to a remote destination may be the
> better option, as we have several servers and at least one of the
> databases residing on them results in an almost 2GB backup file (with
> most of the remainder smaller than that). I'm also unsure of exactly
> how to go about this.
> I believe SQL Server has been installed by default under the local
> system account, so I'm wondering if this will limit my options with
> regard to authentication across servers.
> I've read about the BACKUP command, "log shipping" and other options,
> but am not sure if any match our requirements.
> If anyone could shine a light down the right path for me, my blood
> pressure would be grateful. ;)
>
I've spent the afternoon reading old newsgroup posts and BOL but am
still a bit confused about the best way to approach a new backup
scheme.
My organization would like to establish a single repository for backups
from our database servers, by either backing up databases on each
server and then moving them to the new, central server in some
automated fashion, or by simply pointing to the remote server as the
backup device.
>From a network performance standpoint I think backing up locally and
then copying the resulting files to a remote destination may be the
better option, as we have several servers and at least one of the
databases residing on them results in an almost 2GB backup file (with
most of the remainder smaller than that). I'm also unsure of exactly
how to go about this.
I believe SQL Server has been installed by default under the local
system account, so I'm wondering if this will limit my options with
regard to authentication across servers.
I've read about the BACKUP command, "log shipping" and other options,
but am not sure if any match our requirements.
If anyone could shine a light down the right path for me, my blood
pressure would be grateful. ;)vast55555@.yahoo.com wrote:
> Hello,
> I've spent the afternoon reading old newsgroup posts and BOL but am
> still a bit confused about the best way to approach a new backup
> scheme.
> My organization would like to establish a single repository for backups
> from our database servers, by either backing up databases on each
> server and then moving them to the new, central server in some
> automated fashion, or by simply pointing to the remote server as the
> backup device.
>
> then copying the resulting files to a remote destination may be the
> better option, as we have several servers and at least one of the
> databases residing on them results in an almost 2GB backup file (with
> most of the remainder smaller than that). I'm also unsure of exactly
> how to go about this.
> I believe SQL Server has been installed by default under the local
> system account, so I'm wondering if this will limit my options with
> regard to authentication across servers.
> I've read about the BACKUP command, "log shipping" and other options,
> but am not sure if any match our requirements.
> If anyone could shine a light down the right path for me, my blood
> pressure would be grateful. ;)
>
Create a share on your central server, configure SQL to run as a domain
user, grant that domain user permissions to the share, then use the
BACKUP command to backup directly to the UNC for that share. We move a
dozen backups around on our network each night, some of which are
approaching 200GB, there is no noticeable difference between backing up
locally and then copying vs. backing up over the network.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Hi Tracy,
Thanks for your quick response. That sounds like the way to go. One
potential problem is that this is a hosted situation--not in-house--and
I think there may be no domain, but rather isolated machines (I'm not a
network engineer by trade so I'm a bit ignorant here).
Tracy McKibben wrote:
> Create a share on your central server, configure SQL to run as a domain
> user, grant that domain user permissions to the share, then use the
> BACKUP command to backup directly to the UNC for that share. We move a
> dozen backups around on our network each night, some of which are
> approaching 200GB, there is no noticeable difference between backing up
> locally and then copying vs. backing up over the network.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||Performance wise, backing up straight to a remote file share is often faster
than backing up locally and then copying the backup file to the same file
share. But there are other factors to consider. For instance, with backing u
p
straight to the remote file share, if it fails towards to the end due to som
e
network issue, the retry may take longer than just retrying the copy
operation.
Linchi
"vast55555@.yahoo.com" wrote:
> Hello,
> I've spent the afternoon reading old newsgroup posts and BOL but am
> still a bit confused about the best way to approach a new backup
> scheme.
> My organization would like to establish a single repository for backups
> from our database servers, by either backing up databases on each
> server and then moving them to the new, central server in some
> automated fashion, or by simply pointing to the remote server as the
> backup device.
>
> then copying the resulting files to a remote destination may be the
> better option, as we have several servers and at least one of the
> databases residing on them results in an almost 2GB backup file (with
> most of the remainder smaller than that). I'm also unsure of exactly
> how to go about this.
> I believe SQL Server has been installed by default under the local
> system account, so I'm wondering if this will limit my options with
> regard to authentication across servers.
> I've read about the BACKUP command, "log shipping" and other options,
> but am not sure if any match our requirements.
> If anyone could shine a light down the right path for me, my blood
> pressure would be grateful. ;)
>
Backup/copy to remote server
Hello,
I've spent the afternoon reading old newsgroup posts and BOL but am
still a bit confused about the best way to approach a new backup
scheme.
My organization would like to establish a single repository for backups
from our database servers, by either backing up databases on each
server and then moving them to the new, central server in some
automated fashion, or by simply pointing to the remote server as the
backup device.
>From a network performance standpoint I think backing up locally and
then copying the resulting files to a remote destination may be the
better option, as we have several servers and at least one of the
databases residing on them results in an almost 2GB backup file (with
most of the remainder smaller than that). I'm also unsure of exactly
how to go about this.
I believe SQL Server has been installed by default under the local
system account, so I'm wondering if this will limit my options with
regard to authentication across servers.
I've read about the BACKUP command, "log shipping" and other options,
but am not sure if any match our requirements.
If anyone could shine a light down the right path for me, my blood
pressure would be grateful. ;)vast55555@.yahoo.com wrote:
> Hello,
> I've spent the afternoon reading old newsgroup posts and BOL but am
> still a bit confused about the best way to approach a new backup
> scheme.
> My organization would like to establish a single repository for backups
> from our database servers, by either backing up databases on each
> server and then moving them to the new, central server in some
> automated fashion, or by simply pointing to the remote server as the
> backup device.
>>From a network performance standpoint I think backing up locally and
> then copying the resulting files to a remote destination may be the
> better option, as we have several servers and at least one of the
> databases residing on them results in an almost 2GB backup file (with
> most of the remainder smaller than that). I'm also unsure of exactly
> how to go about this.
> I believe SQL Server has been installed by default under the local
> system account, so I'm wondering if this will limit my options with
> regard to authentication across servers.
> I've read about the BACKUP command, "log shipping" and other options,
> but am not sure if any match our requirements.
> If anyone could shine a light down the right path for me, my blood
> pressure would be grateful. ;)
>
Create a share on your central server, configure SQL to run as a domain
user, grant that domain user permissions to the share, then use the
BACKUP command to backup directly to the UNC for that share. We move a
dozen backups around on our network each night, some of which are
approaching 200GB, there is no noticeable difference between backing up
locally and then copying vs. backing up over the network.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Hi Tracy,
Thanks for your quick response. That sounds like the way to go. One
potential problem is that this is a hosted situation--not in-house--and
I think there may be no domain, but rather isolated machines (I'm not a
network engineer by trade so I'm a bit ignorant here).
Tracy McKibben wrote:
> Create a share on your central server, configure SQL to run as a domain
> user, grant that domain user permissions to the share, then use the
> BACKUP command to backup directly to the UNC for that share. We move a
> dozen backups around on our network each night, some of which are
> approaching 200GB, there is no noticeable difference between backing up
> locally and then copying vs. backing up over the network.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||Performance wise, backing up straight to a remote file share is often faster
than backing up locally and then copying the backup file to the same file
share. But there are other factors to consider. For instance, with backing up
straight to the remote file share, if it fails towards to the end due to some
network issue, the retry may take longer than just retrying the copy
operation.
Linchi
"vast55555@.yahoo.com" wrote:
> Hello,
> I've spent the afternoon reading old newsgroup posts and BOL but am
> still a bit confused about the best way to approach a new backup
> scheme.
> My organization would like to establish a single repository for backups
> from our database servers, by either backing up databases on each
> server and then moving them to the new, central server in some
> automated fashion, or by simply pointing to the remote server as the
> backup device.
> >From a network performance standpoint I think backing up locally and
> then copying the resulting files to a remote destination may be the
> better option, as we have several servers and at least one of the
> databases residing on them results in an almost 2GB backup file (with
> most of the remainder smaller than that). I'm also unsure of exactly
> how to go about this.
> I believe SQL Server has been installed by default under the local
> system account, so I'm wondering if this will limit my options with
> regard to authentication across servers.
> I've read about the BACKUP command, "log shipping" and other options,
> but am not sure if any match our requirements.
> If anyone could shine a light down the right path for me, my blood
> pressure would be grateful. ;)
>
I've spent the afternoon reading old newsgroup posts and BOL but am
still a bit confused about the best way to approach a new backup
scheme.
My organization would like to establish a single repository for backups
from our database servers, by either backing up databases on each
server and then moving them to the new, central server in some
automated fashion, or by simply pointing to the remote server as the
backup device.
>From a network performance standpoint I think backing up locally and
then copying the resulting files to a remote destination may be the
better option, as we have several servers and at least one of the
databases residing on them results in an almost 2GB backup file (with
most of the remainder smaller than that). I'm also unsure of exactly
how to go about this.
I believe SQL Server has been installed by default under the local
system account, so I'm wondering if this will limit my options with
regard to authentication across servers.
I've read about the BACKUP command, "log shipping" and other options,
but am not sure if any match our requirements.
If anyone could shine a light down the right path for me, my blood
pressure would be grateful. ;)vast55555@.yahoo.com wrote:
> Hello,
> I've spent the afternoon reading old newsgroup posts and BOL but am
> still a bit confused about the best way to approach a new backup
> scheme.
> My organization would like to establish a single repository for backups
> from our database servers, by either backing up databases on each
> server and then moving them to the new, central server in some
> automated fashion, or by simply pointing to the remote server as the
> backup device.
>>From a network performance standpoint I think backing up locally and
> then copying the resulting files to a remote destination may be the
> better option, as we have several servers and at least one of the
> databases residing on them results in an almost 2GB backup file (with
> most of the remainder smaller than that). I'm also unsure of exactly
> how to go about this.
> I believe SQL Server has been installed by default under the local
> system account, so I'm wondering if this will limit my options with
> regard to authentication across servers.
> I've read about the BACKUP command, "log shipping" and other options,
> but am not sure if any match our requirements.
> If anyone could shine a light down the right path for me, my blood
> pressure would be grateful. ;)
>
Create a share on your central server, configure SQL to run as a domain
user, grant that domain user permissions to the share, then use the
BACKUP command to backup directly to the UNC for that share. We move a
dozen backups around on our network each night, some of which are
approaching 200GB, there is no noticeable difference between backing up
locally and then copying vs. backing up over the network.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Hi Tracy,
Thanks for your quick response. That sounds like the way to go. One
potential problem is that this is a hosted situation--not in-house--and
I think there may be no domain, but rather isolated machines (I'm not a
network engineer by trade so I'm a bit ignorant here).
Tracy McKibben wrote:
> Create a share on your central server, configure SQL to run as a domain
> user, grant that domain user permissions to the share, then use the
> BACKUP command to backup directly to the UNC for that share. We move a
> dozen backups around on our network each night, some of which are
> approaching 200GB, there is no noticeable difference between backing up
> locally and then copying vs. backing up over the network.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||Performance wise, backing up straight to a remote file share is often faster
than backing up locally and then copying the backup file to the same file
share. But there are other factors to consider. For instance, with backing up
straight to the remote file share, if it fails towards to the end due to some
network issue, the retry may take longer than just retrying the copy
operation.
Linchi
"vast55555@.yahoo.com" wrote:
> Hello,
> I've spent the afternoon reading old newsgroup posts and BOL but am
> still a bit confused about the best way to approach a new backup
> scheme.
> My organization would like to establish a single repository for backups
> from our database servers, by either backing up databases on each
> server and then moving them to the new, central server in some
> automated fashion, or by simply pointing to the remote server as the
> backup device.
> >From a network performance standpoint I think backing up locally and
> then copying the resulting files to a remote destination may be the
> better option, as we have several servers and at least one of the
> databases residing on them results in an almost 2GB backup file (with
> most of the remainder smaller than that). I'm also unsure of exactly
> how to go about this.
> I believe SQL Server has been installed by default under the local
> system account, so I'm wondering if this will limit my options with
> regard to authentication across servers.
> I've read about the BACKUP command, "log shipping" and other options,
> but am not sure if any match our requirements.
> If anyone could shine a light down the right path for me, my blood
> pressure would be grateful. ;)
>
Backup/copy to remote server
Hello,
I've spent the afternoon reading old newsgroup posts and BOL but am
still a bit confused about the best way to approach a new backup
scheme.
My organization would like to establish a single repository for backups
from our database servers, by either backing up databases on each
server and then moving them to the new, central server in some
automated fashion, or by simply pointing to the remote server as the
backup device.
>From a network performance standpoint I think backing up locally and
then copying the resulting files to a remote destination may be the
better option, as we have several servers and at least one of the
databases residing on them results in an almost 2GB backup file (with
most of the remainder smaller than that). I'm also unsure of exactly
how to go about this.
I believe SQL Server has been installed by default under the local
system account, so I'm wondering if this will limit my options with
regard to authentication across servers.
I've read about the BACKUP command, "log shipping" and other options,
but am not sure if any match our requirements.
If anyone could shine a light down the right path for me, my blood
pressure would be grateful. ;)
vast55555@.yahoo.com wrote:
> Hello,
> I've spent the afternoon reading old newsgroup posts and BOL but am
> still a bit confused about the best way to approach a new backup
> scheme.
> My organization would like to establish a single repository for backups
> from our database servers, by either backing up databases on each
> server and then moving them to the new, central server in some
> automated fashion, or by simply pointing to the remote server as the
> backup device.
> then copying the resulting files to a remote destination may be the
> better option, as we have several servers and at least one of the
> databases residing on them results in an almost 2GB backup file (with
> most of the remainder smaller than that). I'm also unsure of exactly
> how to go about this.
> I believe SQL Server has been installed by default under the local
> system account, so I'm wondering if this will limit my options with
> regard to authentication across servers.
> I've read about the BACKUP command, "log shipping" and other options,
> but am not sure if any match our requirements.
> If anyone could shine a light down the right path for me, my blood
> pressure would be grateful. ;)
>
Create a share on your central server, configure SQL to run as a domain
user, grant that domain user permissions to the share, then use the
BACKUP command to backup directly to the UNC for that share. We move a
dozen backups around on our network each night, some of which are
approaching 200GB, there is no noticeable difference between backing up
locally and then copying vs. backing up over the network.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||Hi Tracy,
Thanks for your quick response. That sounds like the way to go. One
potential problem is that this is a hosted situation--not in-house--and
I think there may be no domain, but rather isolated machines (I'm not a
network engineer by trade so I'm a bit ignorant here).
Tracy McKibben wrote:
> Create a share on your central server, configure SQL to run as a domain
> user, grant that domain user permissions to the share, then use the
> BACKUP command to backup directly to the UNC for that share. We move a
> dozen backups around on our network each night, some of which are
> approaching 200GB, there is no noticeable difference between backing up
> locally and then copying vs. backing up over the network.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
|||Performance wise, backing up straight to a remote file share is often faster
than backing up locally and then copying the backup file to the same file
share. But there are other factors to consider. For instance, with backing up
straight to the remote file share, if it fails towards to the end due to some
network issue, the retry may take longer than just retrying the copy
operation.
Linchi
"vast55555@.yahoo.com" wrote:
> Hello,
> I've spent the afternoon reading old newsgroup posts and BOL but am
> still a bit confused about the best way to approach a new backup
> scheme.
> My organization would like to establish a single repository for backups
> from our database servers, by either backing up databases on each
> server and then moving them to the new, central server in some
> automated fashion, or by simply pointing to the remote server as the
> backup device.
> then copying the resulting files to a remote destination may be the
> better option, as we have several servers and at least one of the
> databases residing on them results in an almost 2GB backup file (with
> most of the remainder smaller than that). I'm also unsure of exactly
> how to go about this.
> I believe SQL Server has been installed by default under the local
> system account, so I'm wondering if this will limit my options with
> regard to authentication across servers.
> I've read about the BACKUP command, "log shipping" and other options,
> but am not sure if any match our requirements.
> If anyone could shine a light down the right path for me, my blood
> pressure would be grateful. ;)
>
I've spent the afternoon reading old newsgroup posts and BOL but am
still a bit confused about the best way to approach a new backup
scheme.
My organization would like to establish a single repository for backups
from our database servers, by either backing up databases on each
server and then moving them to the new, central server in some
automated fashion, or by simply pointing to the remote server as the
backup device.
>From a network performance standpoint I think backing up locally and
then copying the resulting files to a remote destination may be the
better option, as we have several servers and at least one of the
databases residing on them results in an almost 2GB backup file (with
most of the remainder smaller than that). I'm also unsure of exactly
how to go about this.
I believe SQL Server has been installed by default under the local
system account, so I'm wondering if this will limit my options with
regard to authentication across servers.
I've read about the BACKUP command, "log shipping" and other options,
but am not sure if any match our requirements.
If anyone could shine a light down the right path for me, my blood
pressure would be grateful. ;)
vast55555@.yahoo.com wrote:
> Hello,
> I've spent the afternoon reading old newsgroup posts and BOL but am
> still a bit confused about the best way to approach a new backup
> scheme.
> My organization would like to establish a single repository for backups
> from our database servers, by either backing up databases on each
> server and then moving them to the new, central server in some
> automated fashion, or by simply pointing to the remote server as the
> backup device.
> then copying the resulting files to a remote destination may be the
> better option, as we have several servers and at least one of the
> databases residing on them results in an almost 2GB backup file (with
> most of the remainder smaller than that). I'm also unsure of exactly
> how to go about this.
> I believe SQL Server has been installed by default under the local
> system account, so I'm wondering if this will limit my options with
> regard to authentication across servers.
> I've read about the BACKUP command, "log shipping" and other options,
> but am not sure if any match our requirements.
> If anyone could shine a light down the right path for me, my blood
> pressure would be grateful. ;)
>
Create a share on your central server, configure SQL to run as a domain
user, grant that domain user permissions to the share, then use the
BACKUP command to backup directly to the UNC for that share. We move a
dozen backups around on our network each night, some of which are
approaching 200GB, there is no noticeable difference between backing up
locally and then copying vs. backing up over the network.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||Hi Tracy,
Thanks for your quick response. That sounds like the way to go. One
potential problem is that this is a hosted situation--not in-house--and
I think there may be no domain, but rather isolated machines (I'm not a
network engineer by trade so I'm a bit ignorant here).
Tracy McKibben wrote:
> Create a share on your central server, configure SQL to run as a domain
> user, grant that domain user permissions to the share, then use the
> BACKUP command to backup directly to the UNC for that share. We move a
> dozen backups around on our network each night, some of which are
> approaching 200GB, there is no noticeable difference between backing up
> locally and then copying vs. backing up over the network.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
|||Performance wise, backing up straight to a remote file share is often faster
than backing up locally and then copying the backup file to the same file
share. But there are other factors to consider. For instance, with backing up
straight to the remote file share, if it fails towards to the end due to some
network issue, the retry may take longer than just retrying the copy
operation.
Linchi
"vast55555@.yahoo.com" wrote:
> Hello,
> I've spent the afternoon reading old newsgroup posts and BOL but am
> still a bit confused about the best way to approach a new backup
> scheme.
> My organization would like to establish a single repository for backups
> from our database servers, by either backing up databases on each
> server and then moving them to the new, central server in some
> automated fashion, or by simply pointing to the remote server as the
> backup device.
> then copying the resulting files to a remote destination may be the
> better option, as we have several servers and at least one of the
> databases residing on them results in an almost 2GB backup file (with
> most of the remainder smaller than that). I'm also unsure of exactly
> how to go about this.
> I believe SQL Server has been installed by default under the local
> system account, so I'm wondering if this will limit my options with
> regard to authentication across servers.
> I've read about the BACKUP command, "log shipping" and other options,
> but am not sure if any match our requirements.
> If anyone could shine a light down the right path for me, my blood
> pressure would be grateful. ;)
>
Subscribe to:
Posts (Atom)