Drop tables with unknown names and unknown quantity

This is what I want to do:

1. Delete all tables in database with table names that ends with a
number.
2. Leave all other tables in tact.
3. Table names are unknown.
4. Numbers attached to table names are unknown.
5. Unknown number of tables in database.

For example:
(Tables in database)
Account
Account1
Account2
Binder
Binder1
Binder2
Binder3
......

I want to delete all the tables in the database with the exception
of Account and Binder.

I know that there are no wildcards in the "Drop Table tablename"
syntax. Does anyone have any suggestions on how to write this sql
statement?

Note: I am executing this statement in MS Access with the
"DoCmd.RunSQL sql_statement" command.

Thanks for any help![posted and mailed, please reply in news]

Amy (amarakunthy@.hotmail.com) writes:
> 1. Delete all tables in database with table names that ends with a
> number.
> 2. Leave all other tables in tact.
> 3. Table names are unknown.
> 4. Numbers attached to table names are unknown.
> 5. Unknown number of tables in database.

The simplest way is to say:

SELECT 'DROP TABLE ' + name FROM sysobjects WHERE name LIKE '%[0-9]'

and then cut and paste and run the result. You would do this from
Query Analyzer.

If you would like to do it programmatically, because you are doing
it routinely, you could set up a cursor over sysobjects, and then
use dynamic SQL to drop the tables:

DECLARE @.tbl sysname
DECLARE drop_tbl_cur INSENSITIVE CURSOR FOR
SELECT name FROM sysobjects WHERE name like '%[0-9]'
OPEN CURSOR drop_tbl_cur
WHILE 1 = 1
BEGIN
FETCH drop_tbl_cur INTO @.tbl
IF @.@.fetch_status <> 0
BREAK
EXEC ('DROP TABLE ' + @.tbl)
END
DEALLOCATE drop_tbl_cur

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||I would also add ' AND xtype = 'U' ' in the where statement so that it
includes only user tables. This way it would include any object in the
statement and you would get errors when trying to execute.
it would look something like this:
SELECT 'DROP TABLE ' + name FROM sysobjects WHERE name LIKE '%[0-9] and
xtype = 'U'

MC

"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns951EEFFFCC91AYazorman@.127.0.0.1...
> [posted and mailed, please reply in news]
> Amy (amarakunthy@.hotmail.com) writes:
> > 1. Delete all tables in database with table names that ends with a
> > number.
> > 2. Leave all other tables in tact.
> > 3. Table names are unknown.
> > 4. Numbers attached to table names are unknown.
> > 5. Unknown number of tables in database.
> The simplest way is to say:
> SELECT 'DROP TABLE ' + name FROM sysobjects WHERE name LIKE '%[0-9]'
> and then cut and paste and run the result. You would do this from
> Query Analyzer.
> If you would like to do it programmatically, because you are doing
> it routinely, you could set up a cursor over sysobjects, and then
> use dynamic SQL to drop the tables:
> DECLARE @.tbl sysname
> DECLARE drop_tbl_cur INSENSITIVE CURSOR FOR
> SELECT name FROM sysobjects WHERE name like '%[0-9]'
> OPEN CURSOR drop_tbl_cur
> WHILE 1 = 1
> BEGIN
> FETCH drop_tbl_cur INTO @.tbl
> IF @.@.fetch_status <> 0
> BREAK
> EXEC ('DROP TABLE ' + @.tbl)
> END
> DEALLOCATE drop_tbl_cur
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server SP3 at
> http://www.microsoft.com/sql/techin.../2000/books.asp

Drillthrough is incomplete

I have a strange problem in my cube when drilling down to details.

If I run the following query and leave out the DRILLTHROUGH, I get only one number as result, 7.

The Measure Counter is defined as "COUNT on lines" of the source table. So I expect that the number 7 results from 7 lines in the source table - And when I run an SQL query translated to use the same filter options as WHERE part, I do indeed get 7 lines matching the date and other settings I asked for. Everything ok so far.

When I execute the MDX query with DRILLTHROUGH I get only 3 lines as result - I remove the DRILLTHROUGH again and get 7 as result again... what can be the reason for this?

DRILLTHROUGH SELECT {[Measures].[Counter]} ON 0 FROM [Cube] WHERE ([Final Level].[Level Hierarchy].&[-6], [Action].[Action].&[4], [Submitted Date].[Submitted Date].[Submitted Year].&[2007], [LMU-SL].[LMU-SL Hierarchy].&[3])

Perhaps there are duplicate records at the measure group granularity, therefore in the cube you ended up with only 3 distinct records, but the total value is still correct - 7.|||

Mosha Pasumansky wrote:

Perhaps there are duplicate records at the measure group granularity, therefore in the cube you ended up with only 3 distinct records, but the total value is still correct - 7.

Mosha, thanks for answering.

I understand what you mean, but I can confirm that this is not the reason / solution.

I did confirm that in fact the 7 rows are distinct for the granularity of the measure group. They each have their own primary key in the database, and the measure group is based on this table, on this pk.

I browse the cube in Excel, and there are more combinations like this one where a number of lines is counted in cube ("11" in this other case), 11 distinct lines can be confirmed using sql, but no line at all is returned for drill. If I create my MDX without drillthrough, I get "11" as value for the measure. If I put "drillthrough" before it - I get no results at all.

As always, it is all far more complicated, as you guessed... My original MDX showed 4 dimensions sliced. 3 of them are really dimension on the measure group, these dimensions are joined in as regular to the measure group. The 4th one is a dimension on a measure group with a finer grain, a deeper level of detail as I try to imagine it. This 4th dimension is joined to the finer grain as a regular dimension, and to the measure group queried using m-n joining "back up from finer detail level".

For information, I can display a row count on the detail measure group as well, and these numbers in the cube are also perfectly in line with tests done using sql. But drills to the detail group give no results at all (even if the cube showed some 10 (distinct) detail lines for this dimension, verified using sql.

I suspect the problem is around that m-n from a finer level, since drilling into both measure groups without using this dimensions mix from different grains works perfectly fine. I am quite sure my dimension - measure setup is correct, since all counts in the cube come out the same value as manual sql test comparisons.

I am really a bit worried here with the reliability of SSAS 2005.

I am now cleaning out the db to only host the 7 lines in question as all data available, opposed to 2.5 mill on the queried level and 10 mill lines in the finer grain section to see if that makes any change in the result, and reload the whole SSAS db with this greatly simplified amount of data. I might also use CTP of SP2 to see what happens.

|||

Ralf_from_Europe wrote:

I am now cleaning out the db to only host the 7 lines in question as all data available, opposed to 2.5 mill on the queried level and 10 mill lines in the finer grain section to see if that makes any change in the result, and reload the whole SSAS db with this greatly simplified amount of data.

I think I found out the worst I could imagine: With less data loaded, or better: only data that falls within the area I slice for, I get ALL my 7 lines as result in drill and as cube measure. I did not change any settings in the project or made any changes to the query. I only threw out around 12 mill lines of data from the source db... I really doubt the precision, or maybe better the reliability of SSAS now.

In case anyone wants to know I noticed the difference between the lines given back and not given back: I suspect the problem I have is somewhere along the aggregations build for the cube. Why? The lines that work are in one category of a dimension (a pretty simple one with the order state, 8 items, like in "ordered", "mailed", "received" or "returned" and so). Anyway, the lines that work are in one state, the ones that do not are in another state.

This dimension is NOT used in this example, and also not part of my MDX query, neither with or without the drillthrough part. I suspect there is no aggregation on this dimension since the design wizard did not call an 8 entry dimension worth it. Then again, I did not change the aggregation setup, I only cleaned the source db of other data...

I am SERIOUSLY in doubt now! Trying SP2 CTP now...