Incorrect syntax near 'Go'

Hi,
I am trying to create index on view. First of all in design view I
cannot use Manage Indexes command.(it is disabled)
Then if I try to add Create Index... command in the View Properties I
cannot use statement "GO"
System is prompting me: incorrent syntaxt near 'GO'
If I remove Go everything works well.
I was trying that on different views but I cannot use GO anywhere.
Thank you for help
ArekGO is not a T-SQL command. It is a command for Query Analyzer and OSQL
client apps, to tell them when to fininsh a bach. Look more about batches in
Books OnLine.
--
Dejan Sarka, SQL Server MVP
Associate Mentor
www.SolidQualityLearning.com
"schapopa" <areklubinski@.hotmail.com> wrote in message
news:1112854192.939546.198960@.o13g2000cwo.googlegroups.com...
> Hi,
> I am trying to create index on view. First of all in design view I
> cannot use Manage Indexes command.(it is disabled)
> Then if I try to add Create Index... command in the View Properties I
> cannot use statement "GO"
> System is prompting me: incorrent syntaxt near 'GO'
> If I remove Go everything works well.
> I was trying that on different views but I cannot use GO anywhere.
> Thank you for help
> Arek
>|||You can't put multiple statements in a view definition and GO isn't a
TSQL command anyway - it's a batch separator.
Does the view conform to the rules for indexed views? Maybe that
explains why the index management option is disabled. Query Analyzer is
a much better place to make schema changes so use QA rather than
Enterprise Manager.
--
David Portas
SQL Server MVP
--|||Thank you.
I was looking for all the rules, and couldn't create that indexed view
in Query Analazer anyway. I will read more about those rules.

Incorrect syntax near 'Go'

Hi,
I am trying to create index on view. First of all in design view I
cannot use Manage Indexes command.(it is disabled)
Then if I try to add Create Index... command in the View Properties I
cannot use statement "GO"
System is prompting me: incorrent syntaxt near 'GO'
If I remove Go everything works well.
I was trying that on different views but I cannot use GO anywhere.
Thank you for help
Arek
GO is not a T-SQL command. It is a command for Query Analyzer and OSQL
client apps, to tell them when to fininsh a bach. Look more about batches in
Books OnLine.
Dejan Sarka, SQL Server MVP
Associate Mentor
www.SolidQualityLearning.com
"schapopa" <areklubinski@.hotmail.com> wrote in message
news:1112854192.939546.198960@.o13g2000cwo.googlegr oups.com...
> Hi,
> I am trying to create index on view. First of all in design view I
> cannot use Manage Indexes command.(it is disabled)
> Then if I try to add Create Index... command in the View Properties I
> cannot use statement "GO"
> System is prompting me: incorrent syntaxt near 'GO'
> If I remove Go everything works well.
> I was trying that on different views but I cannot use GO anywhere.
> Thank you for help
> Arek
>
|||You can't put multiple statements in a view definition and GO isn't a
TSQL command anyway - it's a batch separator.
Does the view conform to the rules for indexed views? Maybe that
explains why the index management option is disabled. Query Analyzer is
a much better place to make schema changes so use QA rather than
Enterprise Manager.
David Portas
SQL Server MVP
|||Thank you.
I was looking for all the rules, and couldn't create that indexed view
in Query Analazer anyway. I will read more about those rules.

Incorrect syntax near 'Go'

Hi,
I am trying to create index on view. First of all in design view I
cannot use Manage Indexes command.(it is disabled)
Then if I try to add Create Index... command in the View Properties I
cannot use statement "GO"
System is prompting me: incorrent syntaxt near 'GO'
If I remove Go everything works well.
I was trying that on different views but I cannot use GO anywhere.
Thank you for help
ArekGO is not a T-SQL command. It is a command for Query Analyzer and OSQL
client apps, to tell them when to fininsh a bach. Look more about batches in
Books OnLine.
Dejan Sarka, SQL Server MVP
Associate Mentor
www.SolidQualityLearning.com
"schapopa" <areklubinski@.hotmail.com> wrote in message
news:1112854192.939546.198960@.o13g2000cwo.googlegroups.com...
> Hi,
> I am trying to create index on view. First of all in design view I
> cannot use Manage Indexes command.(it is disabled)
> Then if I try to add Create Index... command in the View Properties I
> cannot use statement "GO"
> System is prompting me: incorrent syntaxt near 'GO'
> If I remove Go everything works well.
> I was trying that on different views but I cannot use GO anywhere.
> Thank you for help
> Arek
>|||You can't put multiple statements in a view definition and GO isn't a
TSQL command anyway - it's a batch separator.
Does the view conform to the rules for indexed views? Maybe that
explains why the index management option is disabled. Query Analyzer is
a much better place to make schema changes so use QA rather than
Enterprise Manager.
David Portas
SQL Server MVP
--|||Thank you.
I was looking for all the rules, and couldn't create that indexed view
in Query Analazer anyway. I will read more about those rules.

Incorrect Scripts using database generate scripts wizard

I am getting incorrect scripts, not an error, on the indexes when I use the database ‘generate scripts’ wizard.This only happens when I have 8 or more tables and on indexes with include columns.It’s getting the index columns mix up the include columns.Here are the scripts I got:

-- From database ‘generate scripts’ wizard with 8 or more tables(Incorrect)--

CREATE UNIQUE NONCLUSTERED INDEX [IX_DimArmType_Lookup] ON [dbo].[DimArmType]

(

[EW_Arm_Type_Skey] ASC,

[Arm_Type_ID] ASC

)

INCLUDE ( [Arm_Type_LD],

[EW_Source_DB_ID]) WITH (PAD_INDEX= OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]

The ‘script index as’ wizard seem to work fine.

--From ‘script index as’ wizard (Correct)--

CREATE UNIQUE NONCLUSTERED INDEX [IX_DimArmType_Lookup] ON [dbo].[DimArmType]

(

[EW_Source_DB_ID] ASC,

[Arm_Type_ID] ASC

)

INCLUDE ( [EW_Arm_Type_Skey],

[Arm_Type_LD]) WITH (PAD_INDEX= OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF) ON [PRIMARY]

This is happening on all SQL 2005 machines I tested, with or without SP1 and hotfixes.

This doesn't sound like an SSIS issue. You might want to try a more appropriate forum.|||This app uses SMO to script out all objects in any 2000 or 2005

database. The source is freely available so you can easily modify

it if it's not to your liking. It generates a separate file for each

object, which is useful for getting all your code into source control

if it isn't already.

http://www.elsasoft.org/tools.htm

inconsistency errors and how to fix them?

One of the db's I support is prone to throwing up inconsistency errors from time to time. The latest problem seems to relate to indexes.

Server: Msg 2511, Level 16, State 1, Line 1
Table error: Object ID 645577338, Index ID 3. Keys out of order on page (1:286818), slots 308 and 309.
Server: Msg 2511, Level 16, State 1, Line 1
Table error: Object ID 645577338, Index ID 3. Keys out of order on page (1:286826), slots 308 and 309.
DBCC results for 'OrderItem'.
There are 9973753 rows in 67394 pages for object 'OrderItem'.
CHECKTABLE found 0 allocation errors and 2 consistency errors in table 'OrderItem' (object ID 645577338).
repair_rebuild is the minimum repair level for the errors found by DBCC CHECKTABLE (Iceland.dbo.OrderItem ).

I could run a DBCC checktable with the options that *might* fix the above. I am also thinking about doing an index rebuild (currently a nightly index defrag is done but no schedule for an index rebuild is in place). Another table is involved. Both table are reasonably large (one is 7 million rows and the other is nearly 10 million rows). These tables are involved in a chain of many to many relationships. I don't know if it's a factor but the chain is circular. However, this doesn't seem to cause problem in other dbs that have the same design.

What would be the recommended approach for:-

a) fixing the current db inconsistencies?
b) finding the underlying cause of the problem to stop it from happening again?

Thank in advance,

CliveMicrosoft Knowledge Base Article - 822747

Included columns in index.. performance implications ?

How detrimental is it to create multiple indexes that have included columns
as opposed to creating composite indexes that include that all those columns
?
I want to add the index with included columns but also concerned about
slowness in performance on writes. Either way I want to create the index..
the only difference will be whether I decide to have those included columns
or not..
ThanksIt is not really a performance decision. It depends if those columns will be
used, for example, on the WHERE clause or just on the SELECT clause. If thes
e
columns will be listed only in the SELECT clause then use included columns.
If you are going to use those columns as a search criteria then included
columns would not help.
Regarding performance, include columns are better because they are only
stored at the leaf level of the index.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:

> How detrimental is it to create multiple indexes that have included column
s
> as opposed to creating composite indexes that include that all those colum
ns
> ?
> I want to add the index with included columns but also concerned about
> slowness in performance on writes. Either way I want to create the index.
.
> the only difference will be whether I decide to have those included column
s
> or not..
> Thanks
>

Included columns in index.. performance implications ?

How detrimental is it to create multiple indexes that have included columns
as opposed to creating composite indexes that include that all those columns
?
I want to add the index with included columns but also concerned about
slowness in performance on writes. Either way I want to create the index..
the only difference will be whether I decide to have those included columns
or not..
Thanks
It is not really a performance decision. It depends if those columns will be
used, for example, on the WHERE clause or just on the SELECT clause. If these
columns will be listed only in the SELECT clause then use included columns.
If you are going to use those columns as a search criteria then included
columns would not help.
Regarding performance, include columns are better because they are only
stored at the leaf level of the index.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:

> How detrimental is it to create multiple indexes that have included columns
> as opposed to creating composite indexes that include that all those columns
> ?
> I want to add the index with included columns but also concerned about
> slowness in performance on writes. Either way I want to create the index..
> the only difference will be whether I decide to have those included columns
> or not..
> Thanks
>

Included columns in index.. performance implications ?

How detrimental is it to create multiple indexes that have included columns
as opposed to creating composite indexes that include that all those columns
?
I want to add the index with included columns but also concerned about
slowness in performance on writes. Either way I want to create the index..
the only difference will be whether I decide to have those included columns
or not..
ThanksIt is not really a performance decision. It depends if those columns will be
used, for example, on the WHERE clause or just on the SELECT clause. If these
columns will be listed only in the SELECT clause then use included columns.
If you are going to use those columns as a search criteria then included
columns would not help.
Regarding performance, include columns are better because they are only
stored at the leaf level of the index.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:
> How detrimental is it to create multiple indexes that have included columns
> as opposed to creating composite indexes that include that all those columns
> ?
> I want to add the index with included columns but also concerned about
> slowness in performance on writes. Either way I want to create the index..
> the only difference will be whether I decide to have those included columns
> or not..
> Thanks
>