Gathering view from sysobjects

Is the statement below full-proof in gathering views defined in a sql server
7.0 database?
select a.name from sysobjects a where a.type = 'V' and a.status > 0
ThanksSELECT table_name FROM information_schema.views
is even easier. Microsoft advises not to access system tables directly, as
they might changed between versions and services packs. The
information_schema views are a set of ANSI standard views to represent
system information that are guaranteed not to change.
Jacco Schalkwijk
SQL Server MVP
"T" <anonymous@.discussions.microsoft.com> wrote in message
news:05B941B1-A86A-40C1-B2EB-CDDA459ED456@.microsoft.com...

quote:

---

> Is the statement below full-proof in gathering views defined in a sql

---

server 7.0 database?

quote:

---

> select a.name from sysobjects a where a.type = 'V' and a.status > 0
> Thanks

---

|||gotya! Thanks a lot!|||To add to Jacco's response, you can exclude system objects using the
OBJECTPROPERTY function like the example below.
SELECT TABLE_SCHEMA, TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'VIEW' AND
OBJECTPROPERTY(
OBJECT_ID(
QUOTENAME(TABLE_SCHEMA) + '.' +
QUOTENAME(TABLE_NAME)
), 'IsMSShipped') = 0
Hope this helps.
Dan Guzman
SQL Server MVP
"T" <anonymous@.discussions.microsoft.com> wrote in message
news:05B941B1-A86A-40C1-B2EB-CDDA459ED456@.microsoft.com...

quote:

---

> Is the statement below full-proof in gathering views defined in a sql

---

server 7.0 database?

quote:

---

> select a.name from sysobjects a where a.type = 'V' and a.status > 0
> Thanks

---

|||This is actually what I was looking for. Many thanks

Gathering view from sysobjects

Is the statement below full-proof in gathering views defined in a sql server 7.0 database
select a.name from sysobjects a where a.type = 'V' and a.status >
ThanksSELECT table_name FROM information_schema.views
is even easier. Microsoft advises not to access system tables directly, as
they might changed between versions and services packs. The
information_schema views are a set of ANSI standard views to represent
system information that are guaranteed not to change.
--
Jacco Schalkwijk
SQL Server MVP
"T" <anonymous@.discussions.microsoft.com> wrote in message
news:05B941B1-A86A-40C1-B2EB-CDDA459ED456@.microsoft.com...
> Is the statement below full-proof in gathering views defined in a sql
server 7.0 database?
> select a.name from sysobjects a where a.type = 'V' and a.status > 0
> Thanks|||gotya! Thanks a lot!|||To add to Jacco's response, you can exclude system objects using the
OBJECTPROPERTY function like the example below.
SELECT TABLE_SCHEMA, TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'VIEW' AND
OBJECTPROPERTY(
OBJECT_ID(
QUOTENAME(TABLE_SCHEMA) + '.' +
QUOTENAME(TABLE_NAME)
), 'IsMSShipped') = 0
--
Hope this helps.
Dan Guzman
SQL Server MVP
"T" <anonymous@.discussions.microsoft.com> wrote in message
news:05B941B1-A86A-40C1-B2EB-CDDA459ED456@.microsoft.com...
> Is the statement below full-proof in gathering views defined in a sql
server 7.0 database?
> select a.name from sysobjects a where a.type = 'V' and a.status > 0
> Thanks|||This is actually what I was looking for. Many thanks

Gathering requirements for SQL Reporting Services

Hello,
I am assigned the task of gathering requirements from business users
for implementing reports using SQL Server Reporting Services. Some of
the questions I have in mind are:
1. What is the purpose of the report?
2. How many users would be using it?
3. Where is the data coming from?
4. What delivery method is required?
5. What is the layout of the report?
What other information would I need before jumping into setting up the
framework and developing the reports?In addition to your list. you can find out.
1. Complexity (like calculated fileds, charts etc) of the reports
2. Whether the reports are to be shown seperate or should be a part of the
program (This question is for Report viewer)
3. The setup of the hardware servers ( this question is for checking the
performance)
4. Licensing issue should be in your checklist as well.
Amarnath
"sandeshmeda@.gmail.com" wrote:
> Hello,
> I am assigned the task of gathering requirements from business users
> for implementing reports using SQL Server Reporting Services. Some of
> the questions I have in mind are:
> 1. What is the purpose of the report?
> 2. How many users would be using it?
> 3. Where is the data coming from?
> 4. What delivery method is required?
> 5. What is the layout of the report?
> What other information would I need before jumping into setting up the
> framework and developing the reports?
>sql

Gathering information about space in a database using transact sq

Hi!,
I want to gather information about the total space, space used and some
others
statistics like the task pad in the enterprise manager, but using a transact
sql script. I didn't find system tables or useful procedures to do that , the
sp_spaceused give some information but I would like to made some statistics
with this values,
any ideas'
thanks!Hi
Run Profiler and Open up taskpad in EM, and see what EM executes agaisnt the
DB. This gives you a good idea of what they are using.
Regards
Mike
"Her" wrote:
> Hi!,
> I want to gather information about the total space, space used and some
> others
> statistics like the task pad in the enterprise manager, but using a transact
> sql script. I didn't find system tables or useful procedures to do that , the
> sp_spaceused give some information but I would like to made some statistics
> with this values,
> any ideas'
> thanks!
>

Gathering information about space in a database using transact sq

Hi!,
I want to gather information about the total space, space used and some
others
statistics like the task pad in the enterprise manager, but using a transact
sql script. I didn't find system tables or useful procedures to do that , th
e
sp_spaceused give some information but I would like to made some statistics
with this values,
any ideas'
thanks!Hi
Run Profiler and Open up taskpad in EM, and see what EM executes agaisnt the
DB. This gives you a good idea of what they are using.
Regards
Mike
"Her" wrote:

> Hi!,
> I want to gather information about the total space, space used and some
> others
> statistics like the task pad in the enterprise manager, but using a transa
ct
> sql script. I didn't find system tables or useful procedures to do that ,
the
> sp_spaceused give some information but I would like to made some statistic
s
> with this values,
> any ideas'
> thanks!
>

Gathering information about space in a database using transact sq

Hi!,
I want to gather information about the total space, space used and some
others
statistics like the task pad in the enterprise manager, but using a transact
sql script. I didn't find system tables or useful procedures to do that , the
sp_spaceused give some information but I would like to made some statistics
with this values,
any ideas?
thanks!
Hi
Run Profiler and Open up taskpad in EM, and see what EM executes agaisnt the
DB. This gives you a good idea of what they are using.
Regards
Mike
"Her" wrote:

> Hi!,
> I want to gather information about the total space, space used and some
> others
> statistics like the task pad in the enterprise manager, but using a transact
> sql script. I didn't find system tables or useful procedures to do that , the
> sp_spaceused give some information but I would like to made some statistics
> with this values,
> any ideas?
> thanks!
>

Gathering Field Descriptions From SAP

I am at the documentation stage of our project and I need Field Descriptions. They have been defined in SAP R/3 (DB2) and I can view them using SE11 command line parameter (It may change fom version to version, I don't know. It is the place where you view tables).
Lets say table X have 10 columns and every column's description has already been entered in SAP. In my situation there is a total amount of 200 tables which comes out appr. 2000 descriptions in return.
My question is as you may guess, Is there a way to gather this descriptions in a form of table(s)? So I can easily use this info for documentation. It maybe a third party tool or a command or a script wahatever. I really need this.

Thanks in advance.I have forgotten to tell that I am using SQL SERVER 2000 and connecting to DB2 via ODBC driver (though it is so slow...).

Gather Format and Store - Right or Wrong

The IT group that I work with has the habit of gathering data,
formatting (i.e. in reports) and then storing the same formated data in
the same database.
I think the practice is wrong. I think the activity is fundamentally
wrong because we are storing the exact same data in a database in two
different locations. Somehow I have the impression that database design
is about "oneness".
I believe that collecting the data and then storing summerized data for
reporting into a data warehouse would be the right solution.
I am getting flack for my viewpoint.
Am I all washed up?That sounds weird. IF the formatted data is stored for performance reasons,
I'd at least have it in
another database. But I prefer to do the report off of the production databa
se (if low activity and
doesn't have perf impact), or have a different database better suited for re
porting off of.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"rlm" <groups@.rlmoore.net> wrote in message
news:1146747407.524001.97330@.j33g2000cwa.googlegroups.com...
> The IT group that I work with has the habit of gathering data,
> formatting (i.e. in reports) and then storing the same formated data in
> the same database.
> I think the practice is wrong. I think the activity is fundamentally
> wrong because we are storing the exact same data in a database in two
> different locations. Somehow I have the impression that database design
> is about "oneness".
> I believe that collecting the data and then storing summerized data for
> reporting into a data warehouse would be the right solution.
> I am getting flack for my viewpoint.
> Am I all washed up?
>

Gather Format and Store - Right or Wrong

The IT group that I work with has the habit of gathering data,
formatting (i.e. in reports) and then storing the same formated data in
the same database.

I think the practice is wrong. I think the activity is fundamentally
wrong because we are storing the exact same data in a database in two
different locations. Somehow I have the impression that database design
is about "oneness".

I believe that collecting the data and then storing summerized data for
reporting into a data warehouse would be the right solution.

I am getting flack for my viewpoint.

Am I all washed up?That sounds weird. IF the formatted data is stored for performance reasons, I'd at least have it in
another database. But I prefer to do the report off of the production database (if low activity and
doesn't have perf impact), or have a different database better suited for reporting off of.

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/

"rlm" <groups@.rlmoore.net> wrote in message
news:1146747407.524001.97330@.j33g2000cwa.googlegro ups.com...
> The IT group that I work with has the habit of gathering data,
> formatting (i.e. in reports) and then storing the same formated data in
> the same database.
> I think the practice is wrong. I think the activity is fundamentally
> wrong because we are storing the exact same data in a database in two
> different locations. Somehow I have the impression that database design
> is about "oneness".
> I believe that collecting the data and then storing summerized data for
> reporting into a data warehouse would be the right solution.
> I am getting flack for my viewpoint.
> Am I all washed up?

Gather Format and Store - Right or Wrong

The IT group that I work with has the habit of gathering data,
formatting (i.e. in reports) and then storing the same formated data in
the same database.
I think the practice is wrong. I think the activity is fundamentally
wrong because we are storing the exact same data in a database in two
different locations. Somehow I have the impression that database design
is about "oneness".
I believe that collecting the data and then storing summerized data for
reporting into a data warehouse would be the right solution.
I am getting flack for my viewpoint.
Am I all washed up?That sounds weird. IF the formatted data is stored for performance reasons, I'd at least have it in
another database. But I prefer to do the report off of the production database (if low activity and
doesn't have perf impact), or have a different database better suited for reporting off of.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"rlm" <groups@.rlmoore.net> wrote in message
news:1146747407.524001.97330@.j33g2000cwa.googlegroups.com...
> The IT group that I work with has the habit of gathering data,
> formatting (i.e. in reports) and then storing the same formated data in
> the same database.
> I think the practice is wrong. I think the activity is fundamentally
> wrong because we are storing the exact same data in a database in two
> different locations. Somehow I have the impression that database design
> is about "oneness".
> I believe that collecting the data and then storing summerized data for
> reporting into a data warehouse would be the right solution.
> I am getting flack for my viewpoint.
> Am I all washed up?
>