archiving analysis server dbs

Hello,

Does anyone know of a way to schedule the archiving of analysis
databases? Seems pretty lame if you can't... The only answer I've gotten
is "maybe in Yukon"...

Thanks.

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!tim groulx <timgru@.verizon.net> wrote in message news:<40c7a141$0$7885$c397aba@.news.newsgroups.ws>...
> Hello,
> Does anyone know of a way to schedule the archiving of analysis
> databases? Seems pretty lame if you can't... The only answer I've gotten
> is "maybe in Yukon"...
> Thanks.
>
> *** Sent via Devdex http://www.devdex.com ***
> Don't just participate in USENET...get rewarded for it!

Since you use a command-line tool (msmdarch.exe) to archive databases,
you can just schedule that using the job scheduler. Either wrap it in
a batch file, put it in a DTS package (that's useful, because you can
then process the database before archiving), or build it into some
sort of script or program that you write yourself.

See "Msmdarch Command" in Books Online for the full syntax.

Simonsql

application with critical database

Dear all

I am a pretty new in the development world fresh from uni. I am doing development on a system that has a security database. Access to the data in that database is pretty important. So in case the main server where the database is stored for soem reason fails or gets compromised i need to have a second copy with the most recent data in that database and keep the application up and running. The data i have is stored in a SQL 2005 database. What are the recomended aproaches for acheiving this needed reliability?

Would running the SQL Agent every 2 minutes do the trick? And replicate the database to another server and then have asecondary deployment on that server running as a backup? Or are there any other means?

Any advice is apreciated.

Sincerely

See if below links can be useful.

http://msdn2.microsoft.com/en-us/library/ms151247.aspx

http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirror.mspx

Apache and SQL Reporting Services

Hi Everyone,
I'm pretty new to reporting services so this might be a dumb question.... A client of mine has asked me to use reporting services to create reports for them but they have apache web servers!!!! Is this even possible? I've seen tons of documentation on reporting services by now but none that says you can use it with Apache? The Apache servers all have .NET 1.1 installed and working but I'm not sure if that's enough to get this working.
Any information you could provide me with would be greatly appreciated...... I want to give my client an educated response to this request and I haven't been able to find much!!
THANKS!!!
PJ

Hi PJ,

The simple reply is you will need IIS installed. RS is not compatible to have Apache instead of IIS.

|||Thanks Brad!! I thought I would get this answer (and I like IIS better anyway so I'm not complaining)!
Thanks Again!
PJ

Anything that you find in SQL object scripts, you can also find them in system tables?

I tried all the INFORMATION_SCHEMA on SQL 2000 and
I see that the system tables hold pretty much everything I am
interested in: Objects names (columns, functions, stored procedures, ...)
stored procedure statements in syscomments table.

My questions are:

If you script your whole database everything you end up having
in the text sql scripts, are those also located in the system tables?
That means i could simply read those system tables to get any information
I would normally look in the sql script files?

Can i quickly generate a SQL statement of all the indexes on my database?

I read many places that Microsoft
says not to modify anything in those tables and not query them since their
structure might change in future SQL versions.

Is it safe to use and rely the system tables?

I basically want to do at least fetching of information i want from the
system tables rather than the SQL script files.
I also want to know if it's pretty safe for me to make changes in these
tables.
Can i rename an object name for example an Index name, a Stored Procedure
name?
Can i add a new column in the syscolumns table for a user table?

Thank youThe SQLDMO script method can be used to script any SQL Server object. You
can also generate scripts from Enterprise, Query Analyzer or from the
command line using the scptxfr.exe utility.

> Is it safe to use and rely the system tables?

Yes and no. The INFORMATION_SCHEMA views are a better source for lots of the
metadata and they are usually recommended as the preferred method whenever
possible. However, the information schema doesn't cover everything (no
indexes for example) so you may still need to make use of system tables for
some things. If you rely only on the features documented in Books Online and
avoid referencing the stuff that isn't explained or that's marked as
"reserved" then you should be fairly safe. Be sensible though and don't use
system tables when you don't have to. Check out the "Meta Data Functions"
topic in Books Online for other alternatives.

In SQL Server 2005 the old system tables are superceded by a new set of
views that give you much more comprehensive and convenient view of the
metadata. The old-style system tables are still supported for backwards
compatibility although they aren't being extended to support new features.
In theory, most things will work in 2005 as in 2000 but it's not going to be
100% so assume some things may need to be fixed if and when you upgrade.

> I also want to know if it's pretty safe for me to make changes in these
> tables.

Never. Not if you value the integrity of your server and your database. All
the things you need to do are supported through procs and DDL statements.
That includes renaming objects and adding new columns. Don't mess with
updates against the system tables.

--
David Portas
SQL Server MVP
--|||>> Is it safe to use and rely the system tables?

> Yes and no. The INFORMATION_SCHEMA views are a better source for lots of
> the metadata and they are usually recommended as the preferred method
> whenever possible. However, the information schema doesn't cover
> everything (no indexes for example) so you may still need to make use of
> system tables for some things. If you rely only on the features documented
> in Books Online and avoid referencing the stuff that isn't explained or
> that's marked as "reserved" then you should be fairly safe. Be sensible
> though and don't use system tables when you don't have to. Check out the
> "Meta Data Functions" topic in Books Online for other alternatives.

I started reading about Meta Data last week in SQL Books Online and I
am interested to learn more. However I can only do one thing at a time so
I am trying to understand the system tables first and find out ways
how/when/why I could and should use them.
I'll check out "Meta Data Functions" to see what they do.

>> I also want to know if it's pretty safe for me to make changes in these
>> tables.

> Never. Not if you value the integrity of your server and your database.
> All the things you need to do are supported through procs and DDL
> statements. That includes renaming objects and adding new columns. Don't
> mess with updates against the system tables.

Understood. I won't make any changes in these tables. You are right if I can
use the supported procs and DDL statements then I'll use them.

Thank you|||>> Is it safe to use and rely the system tables?

> Yes and no. The INFORMATION_SCHEMA views are a better source for lots of
> the metadata and they are usually recommended as the preferred method
> whenever possible. However, the information schema doesn't cover
> everything (no indexes for example) so you may still need to make use of
> system tables for some things. If you rely only on the features documented
> in Books Online and avoid referencing the stuff that isn't explained or
> that's marked as "reserved" then you should be fairly safe. Be sensible
> though and don't use system tables when you don't have to. Check out the
> "Meta Data Functions" topic in Books Online for other alternatives.

I started reading about Meta Data last week in SQL Books Online and I
am interested to learn more. However I can only do one thing at a time so
I am trying to understand the system tables first and find out ways
how/when/why I could and should use them.
I'll check out "Meta Data Functions" to see what they do.

>> I also want to know if it's pretty safe for me to make changes in these
>> tables.

> Never. Not if you value the integrity of your server and your database.
> All the things you need to do are supported through procs and DDL
> statements. That includes renaming objects and adding new columns. Don't
> mess with updates against the system tables.

Understood. I won't make any changes in these tables. You are right if I can
use the supported procs and DDL statements then I'll use them.

Thank you|||serge (sergea@.nospam.ehmail.com) writes:
> I tried all the INFORMATION_SCHEMA on SQL 2000 and
> I see that the system tables hold pretty much everything I am
> interested in: Objects names (columns, functions, stored procedures, ...)
> stored procedure statements in syscomments table.
> My questions are:
> If you script your whole database everything you end up having
> in the text sql scripts, are those also located in the system tables?

Scripting does not place anything in system tables. Creating objects
does. The source code of stored procedures, views, functions, constraints
and a few more objects are in syscomments. However, they are stored in
8000 character slices, and non-trivial to decode.

Tables, indexes and user-defined types are not stored as text as such
in SQL Server, but as scattered pieces which the scripting tools
reassemble.

In any case, you should not really script your databases more than at
most once. View the database as a storage for binary objects, and keep
your source code under version control. (But if you started without
version control, you may need to script once to get yourself a baseline.)

> I read many places that Microsoft
> says not to modify anything in those tables and not query them since their
> structure might change in future SQL versions.
> Is it safe to use and rely the system tables?

As David said, there are new means for retrieving meta data in SQL 2005,
and the old system tables in SQL 2005 become views implemented on top
of these, known as "Compatibility views". They are also marked as
deperecated, and they will surely disappear from a future version of
SQL Server, but this is not likely to happen this decade.

Important is to only use documented columns, and only use columns what
they are documented for. A column which has the short description of
"Reserved", will very likely always have a value of 0 or NULL in SQL 2005.

Personally, I use only the system tables for meta-data access in SQL 2000,
and this is also what I recommend. The INFORMATION_SCHEMA views are not
whole-covering, so mixing both means that you must know two paradigms.
There are also some traps with the views which can cause you to not
get data you expect, or columns may have names which makes promises
they don't live up to. SQL Server MVP Tony Rogerson also liks to point
out that they have scalability problems. Finally, all that uppercase
is ugly. :-)

> I basically want to do at least fetching of information i want from the
> system tables rather than the SQL script files.
> I also want to know if it's pretty safe for me to make changes in these
> tables.

Never make changes directly to system tables, unless you are told to so
by a Microsoft support professional.

> Can i rename an object name for example an Index name, a Stored Procedure
> name?

To rename an index use sp_rename. To rename a stored procedure, drop
the procedure and reload it under the new name.

> Can i add a new column in the syscolumns table for a user table?

Absolutely not! You will corrupt your database.

Please keep in mind that there is a whole lot of internal structures
in SQL Server that are not exposed. When you add a column to a table,
SQL Server may need to update all pages in the tables, to create space
for the column. Query plans for procedures that has SELECT * may need
to be flushed etc.

In fact, in SQL 2005, you don't even have read access to the real system
tables. All you see is views.

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

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Anyone using Excel 2007 as client ?

Overall pretty cool, but apparently you can't select a single level of a dimension in the pivot table.

For instance, I have level Year, Quarter, Month, Week, Day.

Having to look at last week's sales per day, I'd be selecting a specific week and I'd have the Day level only as row labels.

This worked in Excel 2003, but I can't figure out how to leave out the Year, Q, M and Week levels.

In the PivotTable Field List, you have a check box next to the Time dimension, but nothing next to each level in the dimension. So you have to have all levels of the dimension in the rows of the pivot.

This means a lot of useless drillthrough for the users as they go down from Year to Quarter to Month to Week to Days.

Am I missing something ?

In Excel 2007 you can display the Day level only by 'hiding' the other levels. If you drill down to the lowest level day, right click on any item | Show/Hide Fields | Uncheck the Year level - the year level is hidden. Repeat for the other levels you want to hide.

Hope this helps!

|||

Thanks Zaheera it does help, that's what I needed.

I think this is a feature that needs improvement, since I need 17 clicks before I have drilled down to Days, and then removed the levels one by one.

|||

To accomplish this in fewer clicks - you can right click on an item in the highest level | Expand/Collapse | Expand to <lowest level>. In one-click you've drilled down to the lowest level. Now you'll need to hide each level one by one as described above (which can be a pain - I agree). Or you can do this in one-step in VBA (Alt + F11 to open the editor, Cntrl + G to go to the immediate window): Activecell.PivotField.CubeField.HiddenLevels = 3 and the top 3 levels will be hidden at once.