increase aggregations (design storage) programmatically (was "Please help thank

Fact table gets update every day with thousands of records, I been increase the aggregations manually. Is there a way I can increase aggregations (design storage) programmatically . My cub gets process ones in day with VB program. I want to increase aggregations before processing cub through VB.

It's argent

please help me

thanksCan you do a full process? If you're not running into time constraints, then I'd do a full process.|||As fact table's records increases, dont I have to increase the aggregation in the cub?|||No. Aggregations are dimension related, so as long as your not creating new dimensions then you don't have to worry about increasing aggregations. However, if processing time is not an issue, I'd do a full process.|||I am confused according to your statement
When I create cub with single records fact table the aggregations are zero.
When I create cub with thousands of records in fact table the aggregations are 850 or more.|||Here's what I'm trying to say:

The theoretical maximum number of possible aggregations in a cube is the product of the number of levels in each cube dimension. As you add levels and dimensions to a cube, the number of possible aggregations increases exponentially. The higher the number of dimensions and levels in a cube, the greater its complexity. In the example in Figure 2, the Time dimension has four levels, the Customers dimension has five levels, and the Products dimension has five levels. This yields a theoretical maximum number of aggregations of 100 (5 customer levels x 5 product levels x 4 time levels). However, this number increases exponentially as you add dimensions or levels. For example, if you add the Day level to the Time dimension, the theoretical maximum number of aggregations increases to 125 (5 x 5 x 5). Now, suppose you add two more dimensions to this cube, each with three levels. The theoretical maximum number of aggregations increases to 1125 (5 x 5 x 5 x 3 x 3). A cube with nine dimensions containing five levels each yields theoretical maximum number of aggregations of 1,953,125. A cube of this complexity is considered a cube of medium complexity. A cube of high complexity might have 20 dimensions with five levels each and yield a theoretical maximum number of aggregations of approximately 95 trillion. As you can see, you can directly affect the theoretical maximum number of aggregations in a cube by changing the number of dimensions or the number of levels. Having multiple dimensions with deep hierarchies improves the ability of users to perform analysis, but having too many of either can lead to resource problems during querying and processing.

Follow this link for more info...
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ansvcspg.mspx|||Yes I understand that

What I did is, my fact table was MT (no records) I added one dummy record and created cub out of it, basically dimensions contains single level. I have 40 dimensions and 35 measures. I created a script out of it and sending the script to user to create the cub in their analysis server. In the script I had prompt for users data source name. Users fact table contains millions of records. When user processes the cub with millions of records the dimensions will have multiple levels. So user has to recreate the aggregations?

Sorry, I know you are trying to clarify my doubts but I am still confused.

Thank you so much.|||I think I remember now. You're sharing an identical cube structure with someone, but you're each pointing to different data sources, correct?

If that is the case, the user would have to re-process. Especially since the dimensions will have multiple levels once your script has run against their data. With the numbers you've provided, I wouldn't do a full process. However, again, aggregations are based on dimensions, so you don't need to programatically increase the number of aggregations as new records are added to the fact. Even if new dimension levels are being created, I wouldn't increase the number of aggregations. Just select a particular "performance gain level" and let AS do the rest (i.e. 30%). Having said that, you should probably look into usage based optimization. I have a similar sized cube as you've described and I know that there are a lot of wasted aggregations in the cube (fully processed). It only gets updated once a month, so it's not a big deal to do a full process. Remember, as your cube gets more complex, it's unlikely that your users are making the most of that complexity. That's why usage base optimization makes sense. I haven't done usage based optimization "programatically", so I'm no help there.

I hope that makes sense.|||Thanks so much

User doesnt know about analysis server.
I want to provide user to click option to design storage.

After crating the cub on user server,

I am looking for VB code to
1. Count dimension members
2. Design storage

So user doesnt have to do it manually .sql

Increase Aggregation Percentage

Is there a way to force the design aggregation in BIDS to 100%? All of my dimensions have attribute relations defined (as indicated in the designer) yet I can get only around 35% aggregations defined.

My main issue is an Excel pivot table that the user wants to create that has 3 row dimensions. When the Excel pivot table is first built, access is fast, but when the user drills down to bottom level of each dimension, the query takes a long time.

We have a Hyperion Essbase/Analyzer report that shows the same information rather quickly. The difference I can see is that Analyzer has a list bottom function and the cube space in Essbase is very large (I think Essbase builds an aggregation for everything thus the faster access speed).

Aside from increasing the aggregation, I don't know what else to try. I've read the Project Real paper and utilized tips when possible. I'm using the Standard Edition of SQL Server 2005 so my options are limited.

In upcoming Service Pack 2 release of Analysis Services you will see new sample application that allow you to build set of aggregations based on the information logged in the QueryLog. You will browse your cube and then you'd design aggregations that cover the set of queries you'd like to see working faster.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||

What does aggregations imply under partitions in BIDS? I took some dimensions out of my cube and performed some other changes and now get 99% optimization. Yet, performance have not increased to an acceptable level. Again, these are queries down to the lowest level in Excel.

The Fact table has about 4 million records (3 cubes share this information). Does it make any difference if I created separate SQL fact tables; one for each company. Right now, I'm limiting the records by a query in the data source view. All of my cubes are MOLAP so I thought this wouldn't affect cube performace once the cubes are calculated.

It seems that more aggregations are created when I don't create attribute hierarchies between the levels. Shouldn't performance be the best when attribute relations are defined for all hierarchy levels?

I also tried restricting the amount of data to a seven month period (current year) and still no luck.

|||

You can't preaggregate everything in any database. If you have say 10 dimensionlevels of 10 members each the possible aggregation size of these levels is 10^10 cells. Unless you are sitting on a very large base data table this is gonna translate into an aggregation that IS your basedata (as that is the actual number of nonempty combinations that exists). Thus it's a complete waste to materialize this aggregation and it isn't done. The fewer number of rows in basedata you have and the more dimensions/levels etc. the fewer of all possible aggregations actually make sense. What you are seeing is that the top levels are aggregated and comes back quickly as they contain much fewer rows then base data. When you drill down into the bottom you are leaving the aggregations and walking through the basedata instead - thus the slowness. This isn't due to sloppy implementation but a mathematical certainty true of all preaggregated databases. It would be a great service if someone included an explanation of this in the official documentation as people who aren't familiar with cubes normally assume they are insanely fast for everything and then get very disappointed when they're not.

I haven't used Essbase but have used Excel and is guessing that the speeddifference you are seeing is mainly due to Excel as a client writing absolutely horrendous MDX causing it to go a lot slower then the server can do if you write it yourself. Unfortunately nothing much can be done about this except waiting for Excel 2007 and hoping it's better or switching to another client.

As for the optimization number I am a little curious myself but think it is the percentage of possible queries that can be answered by aggregations. If you take away enough dimensions eventually you will have so few that every combination leads to a sensible aggregation and thus a very high percentage. Still when you do your drilldown you enter aggregations that are very large - it should go faster then before but perhaps not sufficiently fast for your purposes.

|||

Is this a different feature than usage based optimization that is available for partitions? Can you elaborate and clarify the differences?

Thanks

|||

Aggregations themselves are identical and as described above. There is a set of aggregations that "makes sense". However if we put size limits on the combined size of all these we have to make a choice of which to materialize or not.

There's two wizards to do this; one is used at designtime and assumes that all queries are as likely to happen. I assume (as it makes sense but don't really know) this means it sorts by estimated size and then takes as many as can fit starting from the smallest.

The other wizard is the usage based you're talking about. This one looks through the querylogs and prioritizes aggregations that are actually used by queries. This would mean you might drop several unused smaller aggregations to fit a larger aggregation that is actually used.

|||

Ravel, I see what you mean about number of combinations that needs to be aggregated. As mentioned, the report that the user wants contains three dimensions at the lowest level in the row, plus two filter and two column dimensions. On further analysis of the report, it looks like we would be better off writing a query against the SQL database. However, I will lose the budget variance and year to date cube members.

In an effort to increase response time, I've been trying to create smaller cubes. As mentioned, I don't have the Enterprise edition so I cannot use partioning. If I limit the number of records by creating a named query in the data source view is it essentially the same as creating separate tables of the limited data? Meaning, is cube calculation speed the only thing I'm sacrificing by using named queries in the data source view?

Finally, does anyone have any comments about my setup? I have one fact table that looks like:
District, Acct, Scenario (actual, budget, budget update), YearMo, Acct Seg1, Acct Seg2, Acct Seg3, Acct Seg4, Acct Seg5, Acct Seg 6, Amount. All fields in the fact table represents the lowest level of detail in a related dimension table.

My dimension members in SQL looks like:
District, Acct (level 0), Acct (level 1), Acct (level 2), Acct (level 3), Acct (level 4)
District, Acct Seg1 (level 0), Acct Seg (level 1), Acct Seg (level 2)
Repeat for Acct Seg 2 to 6, Time, Scenario

Each of the dimension tables joins to a fact table field. Each dimension record in SQL contains all of the member rollup information. All dimensions have attribute relationships defined. I cannot think of a simpler design, but perhaps the simple design is not the optimal design. However, am I correct to assume that once the cubes (MOLAP) are processed, the Excel queries do not access the source SQL Server tables?

|||

"However, am I correct to assume that once the cubes (MOLAP) are processed, the Excel queries do not access the source SQL Server tables?"

Yes.

"In an effort to increase response time, I've been trying to create smaller cubes. As mentioned, I don't have the Enterprise edition so I cannot use partioning. If I limit the number of records by creating a named query in the data source view is it essentially the same as creating separate tables of the limited data? Meaning, is cube calculation speed the only thing I'm sacrificing by using named queries in the data source view?"

I'm not quite sure I understand you here. But if you use Molap you store all data in the AS database as well. If you've used a named query to limit the amount of rows you will have less data both to build the cube with and to read through at querytime. Thus you should have both faster processing and query results at the expense of not having as much data to analyze as before. I have only used AS with partitions so I can't really answer on how to emulate them if you don't have them.

Increase Aggregation Percentage

Is there a way to force the design aggregation in BIDS to 100%? All of my dimensions have attribute relations defined (as indicated in the designer) yet I can get only around 35% aggregations defined.

My main issue is an Excel pivot table that the user wants to create that has 3 row dimensions. When the Excel pivot table is first built, access is fast, but when the user drills down to bottom level of each dimension, the query takes a long time.

We have a Hyperion Essbase/Analyzer report that shows the same information rather quickly. The difference I can see is that Analyzer has a list bottom function and the cube space in Essbase is very large (I think Essbase builds an aggregation for everything thus the faster access speed).

Aside from increasing the aggregation, I don't know what else to try. I've read the Project Real paper and utilized tips when possible. I'm using the Standard Edition of SQL Server 2005 so my options are limited.

In upcoming Service Pack 2 release of Analysis Services you will see new sample application that allow you to build set of aggregations based on the information logged in the QueryLog. You will browse your cube and then you'd design aggregations that cover the set of queries you'd like to see working faster.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||

What does aggregations imply under partitions in BIDS? I took some dimensions out of my cube and performed some other changes and now get 99% optimization. Yet, performance have not increased to an acceptable level. Again, these are queries down to the lowest level in Excel.

The Fact table has about 4 million records (3 cubes share this information). Does it make any difference if I created separate SQL fact tables; one for each company. Right now, I'm limiting the records by a query in the data source view. All of my cubes are MOLAP so I thought this wouldn't affect cube performace once the cubes are calculated.

It seems that more aggregations are created when I don't create attribute hierarchies between the levels. Shouldn't performance be the best when attribute relations are defined for all hierarchy levels?

I also tried restricting the amount of data to a seven month period (current year) and still no luck.

|||

You can't preaggregate everything in any database. If you have say 10 dimensionlevels of 10 members each the possible aggregation size of these levels is 10^10 cells. Unless you are sitting on a very large base data table this is gonna translate into an aggregation that IS your basedata (as that is the actual number of nonempty combinations that exists). Thus it's a complete waste to materialize this aggregation and it isn't done. The fewer number of rows in basedata you have and the more dimensions/levels etc. the fewer of all possible aggregations actually make sense. What you are seeing is that the top levels are aggregated and comes back quickly as they contain much fewer rows then base data. When you drill down into the bottom you are leaving the aggregations and walking through the basedata instead - thus the slowness. This isn't due to sloppy implementation but a mathematical certainty true of all preaggregated databases. It would be a great service if someone included an explanation of this in the official documentation as people who aren't familiar with cubes normally assume they are insanely fast for everything and then get very disappointed when they're not.

I haven't used Essbase but have used Excel and is guessing that the speeddifference you are seeing is mainly due to Excel as a client writing absolutely horrendous MDX causing it to go a lot slower then the server can do if you write it yourself. Unfortunately nothing much can be done about this except waiting for Excel 2007 and hoping it's better or switching to another client.

As for the optimization number I am a little curious myself but think it is the percentage of possible queries that can be answered by aggregations. If you take away enough dimensions eventually you will have so few that every combination leads to a sensible aggregation and thus a very high percentage. Still when you do your drilldown you enter aggregations that are very large - it should go faster then before but perhaps not sufficiently fast for your purposes.

|||

Is this a different feature than usage based optimization that is available for partitions? Can you elaborate and clarify the differences?

Thanks

|||

Aggregations themselves are identical and as described above. There is a set of aggregations that "makes sense". However if we put size limits on the combined size of all these we have to make a choice of which to materialize or not.

There's two wizards to do this; one is used at designtime and assumes that all queries are as likely to happen. I assume (as it makes sense but don't really know) this means it sorts by estimated size and then takes as many as can fit starting from the smallest.

The other wizard is the usage based you're talking about. This one looks through the querylogs and prioritizes aggregations that are actually used by queries. This would mean you might drop several unused smaller aggregations to fit a larger aggregation that is actually used.

|||

Ravel, I see what you mean about number of combinations that needs to be aggregated. As mentioned, the report that the user wants contains three dimensions at the lowest level in the row, plus two filter and two column dimensions. On further analysis of the report, it looks like we would be better off writing a query against the SQL database. However, I will lose the budget variance and year to date cube members.

In an effort to increase response time, I've been trying to create smaller cubes. As mentioned, I don't have the Enterprise edition so I cannot use partioning. If I limit the number of records by creating a named query in the data source view is it essentially the same as creating separate tables of the limited data? Meaning, is cube calculation speed the only thing I'm sacrificing by using named queries in the data source view?

Finally, does anyone have any comments about my setup? I have one fact table that looks like:
District, Acct, Scenario (actual, budget, budget update), YearMo, Acct Seg1, Acct Seg2, Acct Seg3, Acct Seg4, Acct Seg5, Acct Seg 6, Amount. All fields in the fact table represents the lowest level of detail in a related dimension table.

My dimension members in SQL looks like:
District, Acct (level 0), Acct (level 1), Acct (level 2), Acct (level 3), Acct (level 4)
District, Acct Seg1 (level 0), Acct Seg (level 1), Acct Seg (level 2)
Repeat for Acct Seg 2 to 6, Time, Scenario

Each of the dimension tables joins to a fact table field. Each dimension record in SQL contains all of the member rollup information. All dimensions have attribute relationships defined. I cannot think of a simpler design, but perhaps the simple design is not the optimal design. However, am I correct to assume that once the cubes (MOLAP) are processed, the Excel queries do not access the source SQL Server tables?

|||

"However, am I correct to assume that once the cubes (MOLAP) are processed, the Excel queries do not access the source SQL Server tables?"

Yes.

"In an effort to increase response time, I've been trying to create smaller cubes. As mentioned, I don't have the Enterprise edition so I cannot use partioning. If I limit the number of records by creating a named query in the data source view is it essentially the same as creating separate tables of the limited data? Meaning, is cube calculation speed the only thing I'm sacrificing by using named queries in the data source view?"

I'm not quite sure I understand you here. But if you use Molap you store all data in the AS database as well. If you've used a named query to limit the amount of rows you will have less data both to build the cube with and to read through at querytime. Thus you should have both faster processing and query results at the expense of not having as much data to analyze as before. I have only used AS with partitions so I can't really answer on how to emulate them if you don't have them.

Increase Aggregation Percentage

Is there a way to force the design aggregation in BIDS to 100%? All of my dimensions have attribute relations defined (as indicated in the designer) yet I can get only around 35% aggregations defined.

My main issue is an Excel pivot table that the user wants to create that has 3 row dimensions. When the Excel pivot table is first built, access is fast, but when the user drills down to bottom level of each dimension, the query takes a long time.

We have a Hyperion Essbase/Analyzer report that shows the same information rather quickly. The difference I can see is that Analyzer has a list bottom function and the cube space in Essbase is very large (I think Essbase builds an aggregation for everything thus the faster access speed).

Aside from increasing the aggregation, I don't know what else to try. I've read the Project Real paper and utilized tips when possible. I'm using the Standard Edition of SQL Server 2005 so my options are limited.

In upcoming Service Pack 2 release of Analysis Services you will see new sample application that allow you to build set of aggregations based on the information logged in the QueryLog. You will browse your cube and then you'd design aggregations that cover the set of queries you'd like to see working faster.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||

What does aggregations imply under partitions in BIDS? I took some dimensions out of my cube and performed some other changes and now get 99% optimization. Yet, performance have not increased to an acceptable level. Again, these are queries down to the lowest level in Excel.

The Fact table has about 4 million records (3 cubes share this information). Does it make any difference if I created separate SQL fact tables; one for each company. Right now, I'm limiting the records by a query in the data source view. All of my cubes are MOLAP so I thought this wouldn't affect cube performace once the cubes are calculated.

It seems that more aggregations are created when I don't create attribute hierarchies between the levels. Shouldn't performance be the best when attribute relations are defined for all hierarchy levels?

I also tried restricting the amount of data to a seven month period (current year) and still no luck.

|||

You can't preaggregate everything in any database. If you have say 10 dimensionlevels of 10 members each the possible aggregation size of these levels is 10^10 cells. Unless you are sitting on a very large base data table this is gonna translate into an aggregation that IS your basedata (as that is the actual number of nonempty combinations that exists). Thus it's a complete waste to materialize this aggregation and it isn't done. The fewer number of rows in basedata you have and the more dimensions/levels etc. the fewer of all possible aggregations actually make sense. What you are seeing is that the top levels are aggregated and comes back quickly as they contain much fewer rows then base data. When you drill down into the bottom you are leaving the aggregations and walking through the basedata instead - thus the slowness. This isn't due to sloppy implementation but a mathematical certainty true of all preaggregated databases. It would be a great service if someone included an explanation of this in the official documentation as people who aren't familiar with cubes normally assume they are insanely fast for everything and then get very disappointed when they're not.

I haven't used Essbase but have used Excel and is guessing that the speeddifference you are seeing is mainly due to Excel as a client writing absolutely horrendous MDX causing it to go a lot slower then the server can do if you write it yourself. Unfortunately nothing much can be done about this except waiting for Excel 2007 and hoping it's better or switching to another client.

As for the optimization number I am a little curious myself but think it is the percentage of possible queries that can be answered by aggregations. If you take away enough dimensions eventually you will have so few that every combination leads to a sensible aggregation and thus a very high percentage. Still when you do your drilldown you enter aggregations that are very large - it should go faster then before but perhaps not sufficiently fast for your purposes.

|||

Is this a different feature than usage based optimization that is available for partitions? Can you elaborate and clarify the differences?

Thanks

|||

Aggregations themselves are identical and as described above. There is a set of aggregations that "makes sense". However if we put size limits on the combined size of all these we have to make a choice of which to materialize or not.

There's two wizards to do this; one is used at designtime and assumes that all queries are as likely to happen. I assume (as it makes sense but don't really know) this means it sorts by estimated size and then takes as many as can fit starting from the smallest.

The other wizard is the usage based you're talking about. This one looks through the querylogs and prioritizes aggregations that are actually used by queries. This would mean you might drop several unused smaller aggregations to fit a larger aggregation that is actually used.

|||

Ravel, I see what you mean about number of combinations that needs to be aggregated. As mentioned, the report that the user wants contains three dimensions at the lowest level in the row, plus two filter and two column dimensions. On further analysis of the report, it looks like we would be better off writing a query against the SQL database. However, I will lose the budget variance and year to date cube members.

In an effort to increase response time, I've been trying to create smaller cubes. As mentioned, I don't have the Enterprise edition so I cannot use partioning. If I limit the number of records by creating a named query in the data source view is it essentially the same as creating separate tables of the limited data? Meaning, is cube calculation speed the only thing I'm sacrificing by using named queries in the data source view?

Finally, does anyone have any comments about my setup? I have one fact table that looks like:
District, Acct, Scenario (actual, budget, budget update), YearMo, Acct Seg1, Acct Seg2, Acct Seg3, Acct Seg4, Acct Seg5, Acct Seg 6, Amount. All fields in the fact table represents the lowest level of detail in a related dimension table.

My dimension members in SQL looks like:
District, Acct (level 0), Acct (level 1), Acct (level 2), Acct (level 3), Acct (level 4)
District, Acct Seg1 (level 0), Acct Seg (level 1), Acct Seg (level 2)
Repeat for Acct Seg 2 to 6, Time, Scenario

Each of the dimension tables joins to a fact table field. Each dimension record in SQL contains all of the member rollup information. All dimensions have attribute relationships defined. I cannot think of a simpler design, but perhaps the simple design is not the optimal design. However, am I correct to assume that once the cubes (MOLAP) are processed, the Excel queries do not access the source SQL Server tables?

|||

"However, am I correct to assume that once the cubes (MOLAP) are processed, the Excel queries do not access the source SQL Server tables?"

Yes.

"In an effort to increase response time, I've been trying to create smaller cubes. As mentioned, I don't have the Enterprise edition so I cannot use partioning. If I limit the number of records by creating a named query in the data source view is it essentially the same as creating separate tables of the limited data? Meaning, is cube calculation speed the only thing I'm sacrificing by using named queries in the data source view?"

I'm not quite sure I understand you here. But if you use Molap you store all data in the AS database as well. If you've used a named query to limit the amount of rows you will have less data both to build the cube with and to read through at querytime. Thus you should have both faster processing and query results at the expense of not having as much data to analyze as before. I have only used AS with partitions so I can't really answer on how to emulate them if you don't have them.

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.