Wednesday, March 7, 2012
another deadlock question
info on the box? I set Error 1205 in the filters but still I got lots of
extra info.
--
SQL2K SP3
TIA, ChrisRChris,
Profiler allows you to trace the following deadlock related events:
- Lock:Deadlock
- Lock:Deadlock Chain
Personally, I find the deadlocking info you can get in the errorlog from
trace flag 1205 much more helpful. To turn on this traceflag you just run:
DBCC TRACEON (3605, 1205, -1)
1205 will return info regarding the nodes involved in a deadlock
(when/if they happen). 3605 will log that info to the errorlog. -1
will apply the trace flags to all sessions (i.e. at the server level)
rather than just for the current connection. Turning on the trace flags
this way, however, is not permanent. They'll be reset (i.e. turned off)
again the next time the you stop & restart SQL. To turn them on at
start time, add the following startup parameters to the server using SQLEM:
-T3605 -T1205
Unfortunately these particular trace flags are not documented in SQL BOL
(but they're pretty well known). But BOL does have a little info about
DBCC TRACEON, DBCC TRACEOFF & DBCC TRACESTATUS (as well as SQL startup
options).
Cheers,
Mike
ChrisR wrote:
> Is there a way to run Profiler to trap just deadlock info and not all the
> info on the box? I set Error 1205 in the filters but still I got lots of
> extra info.
> --
> SQL2K SP3
> TIA, ChrisR
>|||> Profiler allows you to trace the following deadlock related events:
> - Lock:Deadlock
> - Lock:Deadlock Chain
Thanks Mike. Im using these. The problem is that I'm still getting back more
info than I like. Which is why Im trying to filter.
"Mike Hodgson" <mwh_junk@.hotmail.com> wrote in message
news:ug60Q4i5EHA.3336@.TK2MSFTNGP11.phx.gbl...
> Chris,
> Profiler allows you to trace the following deadlock related events:
> - Lock:Deadlock
> - Lock:Deadlock Chain
> Personally, I find the deadlocking info you can get in the errorlog from
> trace flag 1205 much more helpful. To turn on this traceflag you just
run:
> DBCC TRACEON (3605, 1205, -1)
> 1205 will return info regarding the nodes involved in a deadlock
> (when/if they happen). 3605 will log that info to the errorlog. -1
> will apply the trace flags to all sessions (i.e. at the server level)
> rather than just for the current connection. Turning on the trace flags
> this way, however, is not permanent. They'll be reset (i.e. turned off)
> again the next time the you stop & restart SQL. To turn them on at
> start time, add the following startup parameters to the server using
SQLEM:
> -T3605 -T1205
> Unfortunately these particular trace flags are not documented in SQL BOL
> (but they're pretty well known). But BOL does have a little info about
> DBCC TRACEON, DBCC TRACEOFF & DBCC TRACESTATUS (as well as SQL startup
> options).
> Cheers,
> Mike
> ChrisR wrote:
> > Is there a way to run Profiler to trap just deadlock info and not all
the
> > info on the box? I set Error 1205 in the filters but still I got lots of
> > extra info.
> >
> > --
> > SQL2K SP3
> >
> > TIA, ChrisR
> >
> >|||The deadlock reporting traceflag is 1204 NOT 1205. That is the source of
the extra information: 1205 export the analysis for every deadlock search,
which is a lock scan looking for a loop, regardless if it finds one. Only
use 1205 if you are have serious deadlock issues and need preemptive
information; otherwise, 1204 should give you sufficient information from any
detected deadlock candidates.
Sincerely,
Anthony Thomas
"ChrisR" <bla@.noemail.com> wrote in message
news:u8DRDRk5EHA.1396@.tk2msftngp13.phx.gbl...
> Profiler allows you to trace the following deadlock related events:
> - Lock:Deadlock
> - Lock:Deadlock Chain
Thanks Mike. Im using these. The problem is that I'm still getting back more
info than I like. Which is why Im trying to filter.
"Mike Hodgson" <mwh_junk@.hotmail.com> wrote in message
news:ug60Q4i5EHA.3336@.TK2MSFTNGP11.phx.gbl...
> Chris,
> Profiler allows you to trace the following deadlock related events:
> - Lock:Deadlock
> - Lock:Deadlock Chain
> Personally, I find the deadlocking info you can get in the errorlog from
> trace flag 1205 much more helpful. To turn on this traceflag you just
run:
> DBCC TRACEON (3605, 1205, -1)
> 1205 will return info regarding the nodes involved in a deadlock
> (when/if they happen). 3605 will log that info to the errorlog. -1
> will apply the trace flags to all sessions (i.e. at the server level)
> rather than just for the current connection. Turning on the trace flags
> this way, however, is not permanent. They'll be reset (i.e. turned off)
> again the next time the you stop & restart SQL. To turn them on at
> start time, add the following startup parameters to the server using
SQLEM:
> -T3605 -T1205
> Unfortunately these particular trace flags are not documented in SQL BOL
> (but they're pretty well known). But BOL does have a little info about
> DBCC TRACEON, DBCC TRACEOFF & DBCC TRACESTATUS (as well as SQL startup
> options).
> Cheers,
> Mike
> ChrisR wrote:
> > Is there a way to run Profiler to trap just deadlock info and not all
the
> > info on the box? I set Error 1205 in the filters but still I got lots of
> > extra info.
> >
> > --
> > SQL2K SP3
> >
> > TIA, ChrisR
> >
> >|||Yep, I always get 1204 & 1205 mixed up - I usually just turn them on one
at a time and you can tell in about 3 seconds which is the right one by
looking at the errorlog (I was going from memory this time). But, yes,
1204 is the traceflag I meant (otherwise, with 1205, the errorlog fills
up rapidly with fairly useless deadlock cycle detection crap).
My apologies for the errata.
Basically, Chris, profiler will not give you enough info to troubleshoot
your deadlocks (at least not without tracing pretty much everything,
which makes finding the info you're after very difficult). You're
better off turning on the traceflag and checking the errorlog next time
a deadlock occurs.
(It's been my observation that the 2 most common questions on
microsoft.public.sqlserver.server are 1) resolving/troubleshooting
deadlocks and 2) shrinking the transaction log.)
Cheers,
Mike.
AnthonyThomas wrote:
> The deadlock reporting traceflag is 1204 NOT 1205. That is the source of
> the extra information: 1205 export the analysis for every deadlock search,
> which is a lock scan looking for a loop, regardless if it finds one. Only
> use 1205 if you are have serious deadlock issues and need preemptive
> information; otherwise, 1204 should give you sufficient information from any
> detected deadlock candidates.
> Sincerely,
>
> Anthony Thomas
>
another deadlock question
info on the box? I set Error 1205 in the filters but still I got lots of
extra info.
SQL2K SP3
TIA, ChrisR
Chris,
Profiler allows you to trace the following deadlock related events:
- Lock:Deadlock
- Lock:Deadlock Chain
Personally, I find the deadlocking info you can get in the errorlog from
trace flag 1205 much more helpful. To turn on this traceflag you just run:
DBCC TRACEON (3605, 1205, -1)
1205 will return info regarding the nodes involved in a deadlock
(when/if they happen). 3605 will log that info to the errorlog. -1
will apply the trace flags to all sessions (i.e. at the server level)
rather than just for the current connection. Turning on the trace flags
this way, however, is not permanent. They'll be reset (i.e. turned off)
again the next time the you stop & restart SQL. To turn them on at
start time, add the following startup parameters to the server using SQLEM:
-T3605 -T1205
Unfortunately these particular trace flags are not documented in SQL BOL
(but they're pretty well known). But BOL does have a little info about
DBCC TRACEON, DBCC TRACEOFF & DBCC TRACESTATUS (as well as SQL startup
options).
Cheers,
Mike
ChrisR wrote:
> Is there a way to run Profiler to trap just deadlock info and not all the
> info on the box? I set Error 1205 in the filters but still I got lots of
> extra info.
> --
> SQL2K SP3
> TIA, ChrisR
>
|||> Profiler allows you to trace the following deadlock related events:
> - Lock:Deadlock
> - Lock:Deadlock Chain
Thanks Mike. Im using these. The problem is that I'm still getting back more
info than I like. Which is why Im trying to filter.
"Mike Hodgson" <mwh_junk@.hotmail.com> wrote in message
news:ug60Q4i5EHA.3336@.TK2MSFTNGP11.phx.gbl...
> Chris,
> Profiler allows you to trace the following deadlock related events:
> - Lock:Deadlock
> - Lock:Deadlock Chain
> Personally, I find the deadlocking info you can get in the errorlog from
> trace flag 1205 much more helpful. To turn on this traceflag you just
run:
> DBCC TRACEON (3605, 1205, -1)
> 1205 will return info regarding the nodes involved in a deadlock
> (when/if they happen). 3605 will log that info to the errorlog. -1
> will apply the trace flags to all sessions (i.e. at the server level)
> rather than just for the current connection. Turning on the trace flags
> this way, however, is not permanent. They'll be reset (i.e. turned off)
> again the next time the you stop & restart SQL. To turn them on at
> start time, add the following startup parameters to the server using
SQLEM:[vbcol=seagreen]
> -T3605 -T1205
> Unfortunately these particular trace flags are not documented in SQL BOL
> (but they're pretty well known). But BOL does have a little info about
> DBCC TRACEON, DBCC TRACEOFF & DBCC TRACESTATUS (as well as SQL startup
> options).
> Cheers,
> Mike
> ChrisR wrote:
the[vbcol=seagreen]
|||The deadlock reporting traceflag is 1204 NOT 1205. That is the source of
the extra information: 1205 export the analysis for every deadlock search,
which is a lock scan looking for a loop, regardless if it finds one. Only
use 1205 if you are have serious deadlock issues and need preemptive
information; otherwise, 1204 should give you sufficient information from any
detected deadlock candidates.
Sincerely,
Anthony Thomas
"ChrisR" <bla@.noemail.com> wrote in message
news:u8DRDRk5EHA.1396@.tk2msftngp13.phx.gbl...
> Profiler allows you to trace the following deadlock related events:
> - Lock:Deadlock
> - Lock:Deadlock Chain
Thanks Mike. Im using these. The problem is that I'm still getting back more
info than I like. Which is why Im trying to filter.
"Mike Hodgson" <mwh_junk@.hotmail.com> wrote in message
news:ug60Q4i5EHA.3336@.TK2MSFTNGP11.phx.gbl...
> Chris,
> Profiler allows you to trace the following deadlock related events:
> - Lock:Deadlock
> - Lock:Deadlock Chain
> Personally, I find the deadlocking info you can get in the errorlog from
> trace flag 1205 much more helpful. To turn on this traceflag you just
run:
> DBCC TRACEON (3605, 1205, -1)
> 1205 will return info regarding the nodes involved in a deadlock
> (when/if they happen). 3605 will log that info to the errorlog. -1
> will apply the trace flags to all sessions (i.e. at the server level)
> rather than just for the current connection. Turning on the trace flags
> this way, however, is not permanent. They'll be reset (i.e. turned off)
> again the next time the you stop & restart SQL. To turn them on at
> start time, add the following startup parameters to the server using
SQLEM:[vbcol=seagreen]
> -T3605 -T1205
> Unfortunately these particular trace flags are not documented in SQL BOL
> (but they're pretty well known). But BOL does have a little info about
> DBCC TRACEON, DBCC TRACEOFF & DBCC TRACESTATUS (as well as SQL startup
> options).
> Cheers,
> Mike
> ChrisR wrote:
the[vbcol=seagreen]
|||Yep, I always get 1204 & 1205 mixed up - I usually just turn them on one
at a time and you can tell in about 3 seconds which is the right one by
looking at the errorlog (I was going from memory this time). But, yes,
1204 is the traceflag I meant (otherwise, with 1205, the errorlog fills
up rapidly with fairly useless deadlock cycle detection crap).
My apologies for the errata.
Basically, Chris, profiler will not give you enough info to troubleshoot
your deadlocks (at least not without tracing pretty much everything,
which makes finding the info you're after very difficult). You're
better off turning on the traceflag and checking the errorlog next time
a deadlock occurs.
(It's been my observation that the 2 most common questions on
microsoft.public.sqlserver.server are 1) resolving/troubleshooting
deadlocks and 2) shrinking the transaction log.)
Cheers,
Mike.
AnthonyThomas wrote:
> The deadlock reporting traceflag is 1204 NOT 1205. That is the source of
> the extra information: 1205 export the analysis for every deadlock search,
> which is a lock scan looking for a loop, regardless if it finds one. Only
> use 1205 if you are have serious deadlock issues and need preemptive
> information; otherwise, 1204 should give you sufficient information from any
> detected deadlock candidates.
> Sincerely,
>
> Anthony Thomas
>
Saturday, February 25, 2012
annoying cut and paste behavior in query analyzer
is there a way to get rid of all those syntax such as
'COLLATE SQL_Latin1_General_CP1_CI_AS '
'[ ]' when cut and paste table script from EM to Query Analyzer?
CREATE TABLE [analyte_property] (
[ESPKEY] [int] NOT NULL ,
[method_1] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_2] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_3] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_4] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_5] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_6] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_7] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_8] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_9] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_10] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY]
GO
it would be ideal to have script look like this
CREATE TABLE analyte_property (
ESPKEY int NOT NULL ,
method_1 char (35) NULL ,
method_2 char (35) NULL ,
method_3 char (35) NULL ,
method_4 char (35) NULL ,
method_5 char (35) NULL ,
method_6 char (35) NULL ,
method_7 char (35) NULL ,
method_8 char (35) NULL ,
method_9 char (35) NULL ,
method_10 char (35) NULL
) ON PRIMARY
GO
Thank you.
Steve,
In the 'Generate sql script' dialog box 'formatting' tab, check the option
'Script sql7 comptatible feature'.
Dinesh
SQL Server MVP
--
SQL Server FAQ at
http://www.tkdinesh.com
"== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
news:Odzd0eSPEHA.252@.TK2MSFTNGP10.phx.gbl...
> background: sql2k on nt5 box..
>
> is there a way to get rid of all those syntax such as
> 'COLLATE SQL_Latin1_General_CP1_CI_AS '
> '[ ]' when cut and paste table script from EM to Query Analyzer?
>
> CREATE TABLE [analyte_property] (
> [ESPKEY] [int] NOT NULL ,
> [method_1] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_2] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_3] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_4] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_5] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_6] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_7] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_8] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_9] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_10] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
> ) ON [PRIMARY]
> GO
> it would be ideal to have script look like this
> CREATE TABLE analyte_property (
> ESPKEY int NOT NULL ,
> method_1 char (35) NULL ,
> method_2 char (35) NULL ,
> method_3 char (35) NULL ,
> method_4 char (35) NULL ,
> method_5 char (35) NULL ,
> method_6 char (35) NULL ,
> method_7 char (35) NULL ,
> method_8 char (35) NULL ,
> method_9 char (35) NULL ,
> method_10 char (35) NULL
> ) ON PRIMARY
> GO
>
> Thank you.
>
>
|||Thank you, but i already knew that.
that's how i got rid of 'COLLATE SQL_Latin1_General_CP1_CI_AS '
when i use EM, genrate sql script function.
i was referring highlight a table in EM, ctrl+c, and ctrl+p in QA.
besides, is there a way to get rid of those square brackets?
"Dinesh T.K" <tkdinesh@.nospam.mail.tkdinesh.com> wrote in message
news:evyaAmSPEHA.2716@.tk2msftngp13.phx.gbl...
> Steve,
> In the 'Generate sql script' dialog box 'formatting' tab, check the option
> 'Script sql7 comptatible feature'.
> --
> Dinesh
> SQL Server MVP
> --
> --
> SQL Server FAQ at
> http://www.tkdinesh.com
> "== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
> news:Odzd0eSPEHA.252@.TK2MSFTNGP10.phx.gbl...
>
|||I've seen this kind of post so many times...
When you use a GUI interface to do programming you get garbage - square
brackets, verbose collation - whatever...
Using EM to design tables, or create indexed is ACCESS-like. EM is the
"lowest common denominator"...
Our first-commandment in our shop is to script everything. We script BULK
INSERT's, INDEX creation, table creation - STORED PROC creation.
That means we create text files, with file extensions of .SQL and use those
in QA to make changes to the database. Not doing it this way would mean we
were a single-stop shop - not developing code for the hundreds of clients we
want to meet.
When we script a SPROC creation we even add the "GRANT..." permission code -
so that the proper DB role has access to the SPROC. If you use EM to output
a script of a SPROC it doesn't contain any GRANT info - that's weak.
Having a text file for every DB change or definition means we can use VISUAL
SOURCE safe... Yadda, yadda, yadda...
Sorry for ranting...
"== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
news:OzjrgJTPEHA.3096@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> Thank you, but i already knew that.
> that's how i got rid of 'COLLATE SQL_Latin1_General_CP1_CI_AS '
> when i use EM, genrate sql script function.
> i was referring highlight a table in EM, ctrl+c, and ctrl+p in QA.
> besides, is there a way to get rid of those square brackets?
>
> "Dinesh T.K" <tkdinesh@.nospam.mail.tkdinesh.com> wrote in message
> news:evyaAmSPEHA.2716@.tk2msftngp13.phx.gbl...
option
>
|||Steve,
None that Iam aware of, except may be a mass replace of 'COLLATE ...' to ''
:-)
[vbcol=seagreen]
Why?In case, any of the column name was like 'method 1' then without [], the
script would fail.
Dinesh
SQL Server MVP
--
SQL Server FAQ at
http://www.tkdinesh.com
"== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
news:OzjrgJTPEHA.3096@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> Thank you, but i already knew that.
> that's how i got rid of 'COLLATE SQL_Latin1_General_CP1_CI_AS '
> when i use EM, genrate sql script function.
> i was referring highlight a table in EM, ctrl+c, and ctrl+p in QA.
> besides, is there a way to get rid of those square brackets?
>
> "Dinesh T.K" <tkdinesh@.nospam.mail.tkdinesh.com> wrote in message
> news:evyaAmSPEHA.2716@.tk2msftngp13.phx.gbl...
option
>
annoying cut and paste behavior in query analyzer
is there a way to get rid of all those syntax such as
'COLLATE SQL_Latin1_General_CP1_CI_AS '
'[ ]' when cut and paste table script from EM to Query Analyzer?
CREATE TABLE [analyte_property] (
[ESPKEY] [int] NOT NULL ,
[method_1] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_2] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_3] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_4] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_5] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_6] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_7] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_8] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_9] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_10] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY]
GO
it would be ideal to have script look like this
CREATE TABLE analyte_property (
ESPKEY int NOT NULL ,
method_1 char (35) NULL ,
method_2 char (35) NULL ,
method_3 char (35) NULL ,
method_4 char (35) NULL ,
method_5 char (35) NULL ,
method_6 char (35) NULL ,
method_7 char (35) NULL ,
method_8 char (35) NULL ,
method_9 char (35) NULL ,
method_10 char (35) NULL
) ON PRIMARY
GO
Thank you.Steve,
In the 'Generate sql script' dialog box 'formatting' tab, check the option
'Script sql7 comptatible feature'.
Dinesh
SQL Server MVP
--
--
SQL Server FAQ at
http://www.tkdinesh.com
"== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
news:Odzd0eSPEHA.252@.TK2MSFTNGP10.phx.gbl...
> background: sql2k on nt5 box..
>
> is there a way to get rid of all those syntax such as
> 'COLLATE SQL_Latin1_General_CP1_CI_AS '
> '[ ]' when cut and paste table script from EM to Query Analyzer?
>
> CREATE TABLE [analyte_property] (
> [ESPKEY] [int] NOT NULL ,
> [method_1] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
> [method_2] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
> [method_3] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
> [method_4] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
> [method_5] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
> [method_6] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
> [method_7] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
> [method_8] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
> [method_9] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
> [method_10] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
> ) ON [PRIMARY]
> GO
> it would be ideal to have script look like this
> CREATE TABLE analyte_property (
> ESPKEY int NOT NULL ,
> method_1 char (35) NULL ,
> method_2 char (35) NULL ,
> method_3 char (35) NULL ,
> method_4 char (35) NULL ,
> method_5 char (35) NULL ,
> method_6 char (35) NULL ,
> method_7 char (35) NULL ,
> method_8 char (35) NULL ,
> method_9 char (35) NULL ,
> method_10 char (35) NULL
> ) ON PRIMARY
> GO
>
> Thank you.
>
>|||Thank you, but i already knew that.
that's how i got rid of 'COLLATE SQL_Latin1_General_CP1_CI_AS '
when i use EM, genrate sql script function.
i was referring highlight a table in EM, ctrl+c, and ctrl+p in QA.
besides, is there a way to get rid of those square brackets?
"Dinesh T.K" <tkdinesh@.nospam.mail.tkdinesh.com> wrote in message
news:evyaAmSPEHA.2716@.tk2msftngp13.phx.gbl...
> Steve,
> In the 'Generate sql script' dialog box 'formatting' tab, check the option
> 'Script sql7 comptatible feature'.
> --
> Dinesh
> SQL Server MVP
> --
> --
> SQL Server FAQ at
> http://www.tkdinesh.com
> "== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
> news:Odzd0eSPEHA.252@.TK2MSFTNGP10.phx.gbl...
>|||I've seen this kind of post so many times...
When you use a GUI interface to do programming you get garbage - square
brackets, verbose collation - whatever...
Using EM to design tables, or create indexed is ACCESS-like. EM is the
"lowest common denominator"...
Our first-commandment in our shop is to script everything. We script BULK
INSERT's, INDEX creation, table creation - STORED PROC creation.
That means we create text files, with file extensions of .SQL and use those
in QA to make changes to the database. Not doing it this way would mean we
were a single-stop shop - not developing code for the hundreds of clients we
want to meet.
When we script a SPROC creation we even add the "GRANT..." permission code -
so that the proper DB role has access to the SPROC. If you use EM to output
a script of a SPROC it doesn't contain any GRANT info - that's weak.
Having a text file for every DB change or definition means we can use VISUAL
SOURCE safe... Yadda, yadda, yadda...
Sorry for ranting...
"== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
news:OzjrgJTPEHA.3096@.TK2MSFTNGP09.phx.gbl...
> Thank you, but i already knew that.
> that's how i got rid of 'COLLATE SQL_Latin1_General_CP1_CI_AS '
> when i use EM, genrate sql script function.
> i was referring highlight a table in EM, ctrl+c, and ctrl+p in QA.
> besides, is there a way to get rid of those square brackets?
>
> "Dinesh T.K" <tkdinesh@.nospam.mail.tkdinesh.com> wrote in message
> news:evyaAmSPEHA.2716@.tk2msftngp13.phx.gbl...
option[vbcol=seagreen]
>|||Steve,
None that Iam aware of, except may be a mass replace of 'COLLATE ...' to ''
:-)
Why?In case, any of the column name was like 'method 1' then without [],
the
script would fail.
Dinesh
SQL Server MVP
--
--
SQL Server FAQ at
http://www.tkdinesh.com
"== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
news:OzjrgJTPEHA.3096@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> Thank you, but i already knew that.
> that's how i got rid of 'COLLATE SQL_Latin1_General_CP1_CI_AS '
> when i use EM, genrate sql script function.
> i was referring highlight a table in EM, ctrl+c, and ctrl+p in QA.
> besides, is there a way to get rid of those square brackets?
>
> "Dinesh T.K" <tkdinesh@.nospam.mail.tkdinesh.com> wrote in message
> news:evyaAmSPEHA.2716@.tk2msftngp13.phx.gbl...
option[vbcol=seagreen]
>
annoying cut and paste behavior in query analyzer
is there a way to get rid of all those syntax such as
'COLLATE SQL_Latin1_General_CP1_CI_AS '
'[ ]' when cut and paste table script from EM to Query Analyzer?
CREATE TABLE [analyte_property] (
[ESPKEY] [int] NOT NULL ,
[method_1] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_2] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_3] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_4] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_5] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_6] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_7] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_8] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_9] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[method_10] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY]
GO
it would be ideal to have script look like this
CREATE TABLE analyte_property (
ESPKEY int NOT NULL ,
method_1 char (35) NULL ,
method_2 char (35) NULL ,
method_3 char (35) NULL ,
method_4 char (35) NULL ,
method_5 char (35) NULL ,
method_6 char (35) NULL ,
method_7 char (35) NULL ,
method_8 char (35) NULL ,
method_9 char (35) NULL ,
method_10 char (35) NULL
) ON PRIMARY
GO
Thank you.Steve,
In the 'Generate sql script' dialog box 'formatting' tab, check the option
'Script sql7 comptatible feature'.
--
Dinesh
SQL Server MVP
--
--
SQL Server FAQ at
http://www.tkdinesh.com
"== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
news:Odzd0eSPEHA.252@.TK2MSFTNGP10.phx.gbl...
> background: sql2k on nt5 box..
>
> is there a way to get rid of all those syntax such as
> 'COLLATE SQL_Latin1_General_CP1_CI_AS '
> '[ ]' when cut and paste table script from EM to Query Analyzer?
>
> CREATE TABLE [analyte_property] (
> [ESPKEY] [int] NOT NULL ,
> [method_1] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_2] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_3] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_4] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_5] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_6] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_7] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_8] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_9] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [method_10] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
> ) ON [PRIMARY]
> GO
> it would be ideal to have script look like this
> CREATE TABLE analyte_property (
> ESPKEY int NOT NULL ,
> method_1 char (35) NULL ,
> method_2 char (35) NULL ,
> method_3 char (35) NULL ,
> method_4 char (35) NULL ,
> method_5 char (35) NULL ,
> method_6 char (35) NULL ,
> method_7 char (35) NULL ,
> method_8 char (35) NULL ,
> method_9 char (35) NULL ,
> method_10 char (35) NULL
> ) ON PRIMARY
> GO
>
> Thank you.
>
>|||Thank you, but i already knew that.
that's how i got rid of 'COLLATE SQL_Latin1_General_CP1_CI_AS '
when i use EM, genrate sql script function.
i was referring highlight a table in EM, ctrl+c, and ctrl+p in QA.
besides, is there a way to get rid of those square brackets?
"Dinesh T.K" <tkdinesh@.nospam.mail.tkdinesh.com> wrote in message
news:evyaAmSPEHA.2716@.tk2msftngp13.phx.gbl...
> Steve,
> In the 'Generate sql script' dialog box 'formatting' tab, check the option
> 'Script sql7 comptatible feature'.
> --
> Dinesh
> SQL Server MVP
> --
> --
> SQL Server FAQ at
> http://www.tkdinesh.com
> "== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
> news:Odzd0eSPEHA.252@.TK2MSFTNGP10.phx.gbl...
> > background: sql2k on nt5 box..
> >
> >
> > is there a way to get rid of all those syntax such as
> > 'COLLATE SQL_Latin1_General_CP1_CI_AS '
> > '[ ]' when cut and paste table script from EM to Query Analyzer?
> >
> >
> >
> > CREATE TABLE [analyte_property] (
> > [ESPKEY] [int] NOT NULL ,
> > [method_1] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > [method_2] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > [method_3] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > [method_4] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > [method_5] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > [method_6] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > [method_7] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > [method_8] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > [method_9] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > [method_10] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
> > ) ON [PRIMARY]
> > GO
> >
> > it would be ideal to have script look like this
> >
> > CREATE TABLE analyte_property (
> > ESPKEY int NOT NULL ,
> > method_1 char (35) NULL ,
> > method_2 char (35) NULL ,
> > method_3 char (35) NULL ,
> > method_4 char (35) NULL ,
> > method_5 char (35) NULL ,
> > method_6 char (35) NULL ,
> > method_7 char (35) NULL ,
> > method_8 char (35) NULL ,
> > method_9 char (35) NULL ,
> > method_10 char (35) NULL
> >
> > ) ON PRIMARY
> > GO
> >
> >
> >
> > Thank you.
> >
> >
> >
>|||I've seen this kind of post so many times...
When you use a GUI interface to do programming you get garbage - square
brackets, verbose collation - whatever...
Using EM to design tables, or create indexed is ACCESS-like. EM is the
"lowest common denominator"...
Our first-commandment in our shop is to script everything. We script BULK
INSERT's, INDEX creation, table creation - STORED PROC creation.
That means we create text files, with file extensions of .SQL and use those
in QA to make changes to the database. Not doing it this way would mean we
were a single-stop shop - not developing code for the hundreds of clients we
want to meet.
When we script a SPROC creation we even add the "GRANT..." permission code -
so that the proper DB role has access to the SPROC. If you use EM to output
a script of a SPROC it doesn't contain any GRANT info - that's weak.
Having a text file for every DB change or definition means we can use VISUAL
SOURCE safe... Yadda, yadda, yadda...
Sorry for ranting...
"== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
news:OzjrgJTPEHA.3096@.TK2MSFTNGP09.phx.gbl...
> Thank you, but i already knew that.
> that's how i got rid of 'COLLATE SQL_Latin1_General_CP1_CI_AS '
> when i use EM, genrate sql script function.
> i was referring highlight a table in EM, ctrl+c, and ctrl+p in QA.
> besides, is there a way to get rid of those square brackets?
>
> "Dinesh T.K" <tkdinesh@.nospam.mail.tkdinesh.com> wrote in message
> news:evyaAmSPEHA.2716@.tk2msftngp13.phx.gbl...
> > Steve,
> >
> > In the 'Generate sql script' dialog box 'formatting' tab, check the
option
> > 'Script sql7 comptatible feature'.
> >
> > --
> > Dinesh
> > SQL Server MVP
> > --
> > --
> > SQL Server FAQ at
> > http://www.tkdinesh.com
> >
> > "== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
> > news:Odzd0eSPEHA.252@.TK2MSFTNGP10.phx.gbl...
> > > background: sql2k on nt5 box..
> > >
> > >
> > > is there a way to get rid of all those syntax such as
> > > 'COLLATE SQL_Latin1_General_CP1_CI_AS '
> > > '[ ]' when cut and paste table script from EM to Query Analyzer?
> > >
> > >
> > >
> > > CREATE TABLE [analyte_property] (
> > > [ESPKEY] [int] NOT NULL ,
> > > [method_1] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_2] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_3] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_4] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_5] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_6] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_7] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_8] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_9] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_10] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
> > > ) ON [PRIMARY]
> > > GO
> > >
> > > it would be ideal to have script look like this
> > >
> > > CREATE TABLE analyte_property (
> > > ESPKEY int NOT NULL ,
> > > method_1 char (35) NULL ,
> > > method_2 char (35) NULL ,
> > > method_3 char (35) NULL ,
> > > method_4 char (35) NULL ,
> > > method_5 char (35) NULL ,
> > > method_6 char (35) NULL ,
> > > method_7 char (35) NULL ,
> > > method_8 char (35) NULL ,
> > > method_9 char (35) NULL ,
> > > method_10 char (35) NULL
> > >
> > > ) ON PRIMARY
> > > GO
> > >
> > >
> > >
> > > Thank you.
> > >
> > >
> > >
> >
> >
>|||Steve,
None that Iam aware of, except may be a mass replace of 'COLLATE ...' to ''
:-)
>> besides, is there a way to get rid of those square brackets?
Why?In case, any of the column name was like 'method 1' then without [], the
script would fail.
--
Dinesh
SQL Server MVP
--
--
SQL Server FAQ at
http://www.tkdinesh.com
"== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
news:OzjrgJTPEHA.3096@.TK2MSFTNGP09.phx.gbl...
> Thank you, but i already knew that.
> that's how i got rid of 'COLLATE SQL_Latin1_General_CP1_CI_AS '
> when i use EM, genrate sql script function.
> i was referring highlight a table in EM, ctrl+c, and ctrl+p in QA.
> besides, is there a way to get rid of those square brackets?
>
> "Dinesh T.K" <tkdinesh@.nospam.mail.tkdinesh.com> wrote in message
> news:evyaAmSPEHA.2716@.tk2msftngp13.phx.gbl...
> > Steve,
> >
> > In the 'Generate sql script' dialog box 'formatting' tab, check the
option
> > 'Script sql7 comptatible feature'.
> >
> > --
> > Dinesh
> > SQL Server MVP
> > --
> > --
> > SQL Server FAQ at
> > http://www.tkdinesh.com
> >
> > "== Steve Pdx==" <lins@.nospam.portptld.com> wrote in message
> > news:Odzd0eSPEHA.252@.TK2MSFTNGP10.phx.gbl...
> > > background: sql2k on nt5 box..
> > >
> > >
> > > is there a way to get rid of all those syntax such as
> > > 'COLLATE SQL_Latin1_General_CP1_CI_AS '
> > > '[ ]' when cut and paste table script from EM to Query Analyzer?
> > >
> > >
> > >
> > > CREATE TABLE [analyte_property] (
> > > [ESPKEY] [int] NOT NULL ,
> > > [method_1] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_2] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_3] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_4] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_5] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_6] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_7] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_8] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_9] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> > > [method_10] [char] (35) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
> > > ) ON [PRIMARY]
> > > GO
> > >
> > > it would be ideal to have script look like this
> > >
> > > CREATE TABLE analyte_property (
> > > ESPKEY int NOT NULL ,
> > > method_1 char (35) NULL ,
> > > method_2 char (35) NULL ,
> > > method_3 char (35) NULL ,
> > > method_4 char (35) NULL ,
> > > method_5 char (35) NULL ,
> > > method_6 char (35) NULL ,
> > > method_7 char (35) NULL ,
> > > method_8 char (35) NULL ,
> > > method_9 char (35) NULL ,
> > > method_10 char (35) NULL
> > >
> > > ) ON PRIMARY
> > > GO
> > >
> > >
> > >
> > > Thank you.
> > >
> > >
> > >
> >
> >
>
Thursday, February 16, 2012
Analysis Services started and then stopped, Event ID: 0xC1210000
I just installed SQL Server 2005 Developer Edition and SP1 and SP2. I cannot start Analysis Services. The message box states: The SQL Server Analysis Services (MSSQLSERVER) service on Local Computer started and then stopped. I looked in the log files located at: C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Log and found these entries:
msmdsrv.log:
(6/15/2007 10:07:34 AM)
Message: The service cannot be started:
(Source: \\?\C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Log\msmdsrv.log,
Type: 3, Category: 289, Event ID: 0xC1210000)
?(6/15/2007 10:10:26 AM) Message:
The service cannot be started:
(Source: \\?\C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Log\msmdsrv.log,
Type: 3, Category: 289, Event ID: 0xC1210000)
During installation I did get an unhandled exception (I don't know what component caused the exception). I have found this in the SQLDUMPER_ERRORLOG.log file:
06/14/07 17:39:38, ERROR , msmdsrv.exe, Unable to open file C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Data\FlightRecorderCurrent.trc, error 2
06/14/07 17:39:38, ACTION, msmdsrv.exe, Watson Invoke: No
Any ideas how to get this service started?
I had the same problem as you discribed. Then I tried to reapply SP2. It works fine now.
I guess when you first applied SP2, analysis service was not installed and therefore the patch is not installed. Download the latest SP2 and try it again:
http://www.microsoft.com/downloads/details.aspx?FamilyId=d07219b2-1e23-49c8-8f0c-63fa18f26d3a&DisplayLang=en
good luck!