Hello,
I am working on a project to reverse engineer requirements for a
database. The database is sitting on a MS SQL Server. How would I
get a listing of all tables and columns within each table to help
create a data dictionary.
I have developed a script in Oracle to do this, but I am just not
familiar with MS SQL Server synthax.
Thanks,
HiteshHi Hitesh
I'm an Oracle developer as well, so sorry for the vagueness...
I think you want to use some stored procedures. sp_tables and sp_columns
are system stored procedures that return the same info as the User_Tables
and User_Tab_Columns views in Oracle.
Do you have the SQL Server client tools installed? Books Online
explains the use of these procedures.
Joe
"Hitesh" <zerocoo_@.hotmail.com> wrote in message
news:30ca6fbb.0405180920.93a5e7c@.posting.google.co m...
> Hello,
> I am working on a project to reverse engineer requirements for a
> database. The database is sitting on a MS SQL Server. How would I
> get a listing of all tables and columns within each table to help
> create a data dictionary.
> I have developed a script in Oracle to do this, but I am just not
> familiar with MS SQL Server synthax.
> Thanks,
> Hitesh|||On 18 May 2004 10:20:24 -0700, Hitesh wrote:
>Hello,
>I am working on a project to reverse engineer requirements for a
>database. The database is sitting on a MS SQL Server. How would I
>get a listing of all tables and columns within each table to help
>create a data dictionary.
>I have developed a script in Oracle to do this, but I am just not
>familiar with MS SQL Server synthax.
>Thanks,
>Hitesh
Hi Hitesh,
All information about all tables:
SELECT * FROM INFORMATION_SCHEMA.TABLES
All information about all columns:
SELECT * FROM INFORMATION_SCHEMA.COLUMNS
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||If you have Enterprise Manager, you can also create Database Diagrams
containing some or all of the tables.
"Hitesh" <zerocoo_@.hotmail.com> wrote in message
news:30ca6fbb.0405180920.93a5e7c@.posting.google.co m...
> Hello,
> I am working on a project to reverse engineer requirements for a
> database. The database is sitting on a MS SQL Server. How would I
> get a listing of all tables and columns within each table to help
> create a data dictionary.
> I have developed a script in Oracle to do this, but I am just not
> familiar with MS SQL Server synthax.
> Thanks,
> Hitesh|||thanks...someone also suggested using the following
/*P = Stored Procedure
U = Table
PK = Primary Key
V = View
TR = Trigger
the 'xtype' is the type of object it is */
select so.name as obj_name,
sc.name as colm_name,
so.xtype
from sysobjects so (nolock),
syscolumns sc (nolock)
where so.id *= sc.id
order by so.name, sc.name
the above command seems to be more comprehensive than using
information_schema. when run the above query, i get hidden system
tables and approximately 600 rows of data, where as the
information_schema comman queries 250+ rows. anyone know what is the
difference between these two? thanks
SELECT * FROM INFORMATION_SCHEMA.TABLES
SELECT * FROM INFORMATION_SCHEMA.COLUMNS
Hugo Kornelis <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message news:<9enka0p0p32mn2smhjp5rgmc9an0c973af@.4ax.com>...
> On 18 May 2004 10:20:24 -0700, Hitesh wrote:
> >Hello,
> >I am working on a project to reverse engineer requirements for a
> >database. The database is sitting on a MS SQL Server. How would I
> >get a listing of all tables and columns within each table to help
> >create a data dictionary.
> >I have developed a script in Oracle to do this, but I am just not
> >familiar with MS SQL Server synthax.
> >Thanks,
> >Hitesh
> Hi Hitesh,
> All information about all tables:
> SELECT * FROM INFORMATION_SCHEMA.TABLES
> All information about all columns:
> SELECT * FROM INFORMATION_SCHEMA.COLUMNS
>
> Best, Hugo|||On 19 May 2004 09:16:57 -0700, Hitesh wrote:
>thanks...someone also suggested using the following
>/*P = Stored Procedure
>U = Table
>PK = Primary Key
>V = View
>TR = Trigger
>the 'xtype' is the type of object it is */
>select so.name as obj_name,
>sc.name as colm_name,
>so.xtype
>from sysobjects so (nolock),
>syscolumns sc (nolock)
>where so.id *= sc.id
>order by so.name, sc.name
>
>the above command seems to be more comprehensive than using
>information_schema. when run the above query, i get hidden system
>tables and approximately 600 rows of data, where as the
>information_schema comman queries 250+ rows. anyone know what is the
>difference between these two? thanks
>SELECT * FROM INFORMATION_SCHEMA.TABLES
>SELECT * FROM INFORMATION_SCHEMA.COLUMNS
Hi Hitesh,
The query you issued against the system tables will also include stored
procedures, constraints, triggers etc. That should explain the different
number of rows.
There is nothing wring with directly querying the system tables if you
really know what you're doing and if you're not bothered by upward
compatibility. The INFORMATIION_SCHEMA views conform to the ANSI standard
for SQL. If the structure of the system tables is changed in a future
version, the INFORMATION_SCHEMA views will be changed as well, to ensure
ANSI compliance. You'll have to modify your queries against the system
tables yourself.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||thanks for clarifying
Hugo Kornelis <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message news:<hgfna09uu6p3q9l5h1u4shr8uvq250pm4k@.4ax.com>...
> On 19 May 2004 09:16:57 -0700, Hitesh wrote:
> >thanks...someone also suggested using the following
> >/*P = Stored Procedure
> >U = Table
> >PK = Primary Key
> >V = View
> >TR = Trigger
> >the 'xtype' is the type of object it is */
> >select so.name as obj_name,
> >sc.name as colm_name,
> >so.xtype
> >from sysobjects so (nolock),
> >syscolumns sc (nolock)
> >where so.id *= sc.id
> >order by so.name, sc.name
> >the above command seems to be more comprehensive than using
> >information_schema. when run the above query, i get hidden system
> >tables and approximately 600 rows of data, where as the
> >information_schema comman queries 250+ rows. anyone know what is the
> >difference between these two? thanks
> >SELECT * FROM INFORMATION_SCHEMA.TABLES
> >SELECT * FROM INFORMATION_SCHEMA.COLUMNS
> Hi Hitesh,
> The query you issued against the system tables will also include stored
> procedures, constraints, triggers etc. That should explain the different
> number of rows.
> There is nothing wring with directly querying the system tables if you
> really know what you're doing and if you're not bothered by upward
> compatibility. The INFORMATIION_SCHEMA views conform to the ANSI standard
> for SQL. If the structure of the system tables is changed in a future
> version, the INFORMATION_SCHEMA views will be changed as well, to ensure
> ANSI compliance. You'll have to modify your queries against the system
> tables yourself.
> Best, Hugo