Is there a system table containing the information if a package has been success

Hi all,
Im not really sure if this is a PHP or and SQL problem but here goes.

Im using MSSQL and have developed a webpage that enables users to run various PACKAGES manually, however I need to display if the package has been successfully run.

Is there a system table that logs package information or is there a PHP function that I can use.

Thanks

P.s I know there are some system tables with the information for jobs but I do not want to create a job for each package.If you say about DTS... then you can find it in msdb database
msdb..sysdtspackagelog... and etc.

Is there a System Stored Procedure that scripts tables?

Hello
I wonder if I can generate the "CREATE TABLE" sentence given the name of a table by means of a stored procedure.
Thanks a lot.Hello

I wonder if I can generate the "CREATE TABLE" sentence given the name of a table by means of a stored procedure.

Thanks a lot.

I think you need the Server Management Objects (SMO) to do what you are thinking of. SMO works in SQL 2005. There's an earlier version of it in SQL 2000, but for the life of me, I can't remember the name right now.

Regards,

hmscott|||I imagine you could create one by using Profiler to examine what happens when you right click a table in Enterprise Manager select "All Tasks -> Generate SQL Script -> Preview". Be aware ahead of time, it's not a one-step process...|||This free console app I wrote may be of use to you. it will generate scripts for all objects in any 2000 or 2005 database. open source so you can tweak it if you want. it uses SMO.

I wrote it as a way to easily export the DDL for a database for checkin to a source control system.

http://www.elsasoft.org/tools.htm

hope it's useful to you!|||Thanks a lot!sql

Is there a system generated row id in SQL Server 2000?

Hi,
I wanted to perform a select and a delete of a row based on a system generat
ed row id (like what Oracle has). However after researching this issue I've
found that there is no equivalent of Oracle Rowid in SQL Server.
I know I can generate my own row numbers using identity columns and then pro
cess the results but I was curious to know whether or not SQL Server actuall
y had a system generated row id. My thinking was that each row has to have a
row id because otherwise h
ow will b-tree indexes work (especially on non unique columns)?
Documentation doesn't really give out much information on what the Row struc
ture looks like in SQL Server (or at least I haven't been able to find it) n
ot have I found information on exactly what does a row pointer looks like in
a B-Tree index leaf page.
Can anyone suggest a source of information on the above? Also, if there is a
system generated row id in SQL Server, is any way at all of accessing it?hi;
am not a SQL expert here, but i think there is a datatype call IDENTITY that
auto generate an sequencing row number. that cld be what u need.
amnyone can verify ?
"SJ" <anonymous@.discussions.microsoft.com> wrote in message
news:1196BF60-EF0E-4E47-853F-18E79C95279E@.microsoft.com...
> Hi,
> I wanted to perform a select and a delete of a row based on a system
generated row id (like what Oracle has). However after researching this
issue I've found that there is no equivalent of Oracle Rowid in SQL Server.
> I know I can generate my own row numbers using identity columns and then
process the results but I was curious to know whether or not SQL Server
actually had a system generated row id. My thinking was that each row has to
have a row id because otherwise how will b-tree indexes work (especially on
non unique columns)?
> Documentation doesn't really give out much information on what the Row
structure looks like in SQL Server (or at least I haven't been able to find
it) not have I found information on exactly what does a row pointer looks
like in a B-Tree index leaf page.
> Can anyone suggest a source of information on the above? Also, if there is
a system generated row id in SQL Server, is any way at all of accessing it?|||You will have to generate your own rowid... SQL does not expose one ( as
some other DBMS's do.)
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"SJ" <anonymous@.discussions.microsoft.com> wrote in message
news:1196BF60-EF0E-4E47-853F-18E79C95279E@.microsoft.com...
> Hi,
> I wanted to perform a select and a delete of a row based on a system
generated row id (like what Oracle has). However after researching this
issue I've found that there is no equivalent of Oracle Rowid in SQL Server.
> I know I can generate my own row numbers using identity columns and then
process the results but I was curious to know whether or not SQL Server
actually had a system generated row id. My thinking was that each row has to
have a row id because otherwise how will b-tree indexes work (especially on
non unique columns)?
> Documentation doesn't really give out much information on what the Row
structure looks like in SQL Server (or at least I haven't been able to find
it) not have I found information on exactly what does a row pointer looks
like in a B-Tree index leaf page.
> Can anyone suggest a source of information on the above? Also, if there is
a system generated row id in SQL Server, is any way at all of accessing it?|||Yes I think the keywords here are "sql does not expose one". I have been sus
pecting that although there may be a system generated row id, it wouldn't be
accesible to external users.|||To the best of my knowledge there really isn't one.
I don't worry about internal page strcutures all that much, so I could be
wrong. I'm sure Kalen's book Inside SQL Server 2000 would have a lot of
great info on this topic if you're really interested.
But to the best of my knowledge, internal id's are based on both page number
and row offset (or a row number) on that specific page. I do not believe
there is an internal ID that is unique across a table space. The short
answer is that it doesn't matter since there definitely isn't one exposed.
But I don't think one even exists...
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"SJ" <anonymous@.discussions.microsoft.com> wrote in message
news:56E22894-9ACE-4654-B93B-7E375D21A367@.microsoft.com...
> Yes I think the keywords here are "sql does not expose one". I have been
suspecting that although there may be a system generated row id, it wouldn't
be accesible to external users.|||Brian is correct - there is no exposed unique RID for a row.
There are two types of RIDs we use internally, physical and logical.
Physical RIDs are F:P:S, where F is the file ID, P is the page number in the
file and S is the slot number on the page. These are only used for locating
heap rows from non-clustered indexes over heaps (i.e. each row in a
non-clustered index over a heap contains the physical RID of the
corresponding row in the heap itself). Physical RIDs are not exposed,
although you will see them sometimes in DBCC CHECK* error messages.
Logical RIDs are the keys of the index the row belongs too. Each row in a
non-clustered index has a logical RID. Each row in a non-clustered index
over a clustered index also contains the logical RID of the corresponding
row in the clustered index).
Regards.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Brian Moran" <brian@.solidqualitylearning.com> wrote in message
news:eSCl$8zEEHA.2404@.TK2MSFTNGP11.phx.gbl...
> To the best of my knowledge there really isn't one.
> I don't worry about internal page strcutures all that much, so I could be
> wrong. I'm sure Kalen's book Inside SQL Server 2000 would have a lot of
> great info on this topic if you're really interested.
> But to the best of my knowledge, internal id's are based on both page
number
> and row offset (or a row number) on that specific page. I do not believe
> there is an internal ID that is unique across a table space. The short
> answer is that it doesn't matter since there definitely isn't one exposed.
> But I don't think one even exists...
> --
> Brian Moran
> Principal Mentor
> Solid Quality Learning
> SQL Server MVP
> http://www.solidqualitylearning.com
>
> "SJ" <anonymous@.discussions.microsoft.com> wrote in message
> news:56E22894-9ACE-4654-B93B-7E375D21A367@.microsoft.com...
> suspecting that although there may be a system generated row id, it
wouldn't
> be accesible to external users.
>|||Thank you all for you responses.|||The only thing I would add is the reason that SQL Server doesn't expose row
ids. Systems that expose row ids require more offline and manual
maintenance than systems that don't expose row ids. That's because systems
that expose row ids can't just move rows around without breaking
applications. Systems that don't expose row ids can dynamically reorganize
data at any time since no user will ever request the data by rowid.
First generation systems such as Rdb and Oracle exposed rowids, second
generation systems such as Tandem and Sybase saw the errors in this and did
not expose them. Of course once exposed it's almost impossible to take away
the feature, so Oracle still has it.
Hal Berenson, SQL Server MVP
VP, Yukon Readiness
Scalability Experts, Inc.
"Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
news:uyL9fz3EEHA.1456@.TK2MSFTNGP09.phx.gbl...
> Brian is correct - there is no exposed unique RID for a row.
> There are two types of RIDs we use internally, physical and logical.
> Physical RIDs are F:P:S, where F is the file ID, P is the page number in
the
> file and S is the slot number on the page. These are only used for
locating
> heap rows from non-clustered indexes over heaps (i.e. each row in a
> non-clustered index over a heap contains the physical RID of the
> corresponding row in the heap itself). Physical RIDs are not exposed,
> although you will see them sometimes in DBCC CHECK* error messages.
> Logical RIDs are the keys of the index the row belongs too. Each row in a
> non-clustered index has a logical RID. Each row in a non-clustered index
> over a clustered index also contains the logical RID of the corresponding
> row in the clustered index).
> Regards.
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "Brian Moran" <brian@.solidqualitylearning.com> wrote in message
> news:eSCl$8zEEHA.2404@.TK2MSFTNGP11.phx.gbl...
be
> number
exposed.
been
> wouldn't
>

is there a syntax t-sql for generate sql scripts.

Is there syntaxs t-sql, function or others to generate
sql script of objects (table, view, stored procedure,..)?
I know we can do manualy from right click and then click
generate all scripts ? but can we do it with programming ?
thanks.For most stored procedures (assuming they are <= 8000 characters) you can
use sp_helptext, you can also SELECT ROUTINE_DEFINITION FROM
INFORMATION_SCHEMA.ROUTINES in your script.
For tables, it's a little more complicated, especially if you have
primary/foreign keys, constraints, default values, etc. I think if you're
going about it this way: create the tables, then script them properly, you
should think about doing it the other way around. :-)
"kresna rudy kurniawan" <kresna_rk@.hotmail.com> wrote in message
news:03e901c39c3b$d15a5eb0$a401280a@.phx.gbl...
> Is there syntaxs t-sql, function or others to generate
> sql script of objects (table, view, stored procedure,..)?
> I know we can do manualy from right click and then click
> generate all scripts ? but can we do it with programming ?
> thanks.|||> generate all scripts ? but can we do it with programming ?
Your best bet is SQL-DMO. Though you can invoke SQL-DMO objects and their
Script methods via T-SQL's sp_OAxxx procedures, you are much better off
using a scripting language such as VB or Perl.
Of course, if you like to do it the hard way and like to re-invent the
wheel, you can always query the system tables and construct the scripts
entirely in T-SQL. That won't be pretty though.
--
Linchi Shea
linchi_shea@.NOSPAMml.com
"kresna rudy kurniawan" <kresna_rk@.hotmail.com> wrote in message
news:03e901c39c3b$d15a5eb0$a401280a@.phx.gbl...
> Is there syntaxs t-sql, function or others to generate
> sql script of objects (table, view, stored procedure,..)?
> I know we can do manualy from right click and then click
> generate all scripts ? but can we do it with programming ?
> thanks.

Is there a style sheet or theme sheet available for reports

I'm currently building several reports which need an identical look/feel to them. I know that I could create a template which would incorporate any of its properties into any new report that uses it. However, it doesn't look like those properties are inherited by the child report. I need to be able to modify the look/feel of all my reports and I'd rather not have to make updates to each individual report. Is there a way to either set up the template or create a style sheet to accomodate this?No. This is a great suggestion for future versions of the product. You can add a report as a template in Report Designer, but there is no template that can be applied to reports already deployed to modify common report items.

Is there a statement to view table description in MS SQL

In Oracle I could type "Desc <table name> " to get the table and column information. Is there a similar statement in SQL 2000 to view a table description?right click the table and select "Design Table"|||I am using Query Analyzer to execute the SQL statment. I can not find Design Table in Query Analyzer. Please provide me more info.

Thanks|||In query analyzer, you can use SP_COLUMNS [table name] to get a list of all the columns of a table, along with all the properties of those columns.

I would recommend using "results in grid" to see the results.

Or for far more details about your table, you could use SP_HELP [table name]. This would give you several results about the table.

But I believe SP_COLUMNS will answer your question.sql

Is there a SQLXML 4 version in the works?

Saw a post on another message board dated Feb '02 from Michael Brundage:
"FWIW, the next version of SQLXML will interoperate much better with the rest of .Net.
The .Net classes we released in SQLXML3 were only a partial solution. And of course
as you yourself observed, the .Net frameworks themselves are just in their very first
version, and will evolve over time to better handle your scenarios."
Is there a V4 coming that integrates better with .NET, and doesnt do so much interop?
"Paul Hester" <phester@.microsoft.com> wrote in message
news:C9EB80D2-B29F-4963-AFA2-E1DD68D69DA0@.microsoft.com...
[snip]
> Is there a V4 coming that integrates better with .NET, and doesnt do so
much interop?
Yes. SqlXml 4.0 will also be know as SQL Server 2005.
Bryant
|||Obviously Yukon will have fantastic XML support compared to SQLXML 3Sp2. But Yukon being deployed in large numbers is still over at least a year and a half away, likely more.
|||We are planning a release with Sql Server 2005, but it will be updates to
the current technology.
Are you having any issues with interop? Or is it just that interop is in
fact there?
Irwin Dolobowsky
Program Manager - SqlXml
http://blogs.msdn.com/irwando
This posting is provided "AS IS" with no warranties, and confers no rights.
"Paul Hester" <phester@.microsoft.com> wrote in message
news:C9EB80D2-B29F-4963-AFA2-E1DD68D69DA0@.microsoft.com...
> Saw a post on another message board dated Feb '02 from Michael Brundage:
> "FWIW, the next version of SQLXML will interoperate much better with the
> rest of .Net.
> The .Net classes we released in SQLXML3 were only a partial solution. And
> of course
> as you yourself observed, the .Net frameworks themselves are just in their
> very first
> version, and will evolve over time to better handle your scenarios."
> Is there a V4 coming that integrates better with .NET, and doesnt do so
> much interop?
|||We're considering using SQLXML as the primary interface to SQL for our new .NET OLTP architecture, as it provides the very attractive means of using XSD'd as a layer over the database. Obviously we'd like our new applications to perform. However, it seems
there is considerable overhead to this. XML parsing and XSD mapping (which we understand is inherent in using XML), combined with the interop and OLEDB layers, and that the more versatile and compact updategrams aren't directly supported in DataSets (we
considered developing our own methods to iterate over a DataSet's schema and tables, etc. to generate) has left us questioning the viability of using SQLXML. It's my sense SQLXML could be much more intergrated with .NET, with more (or all) of it implement
ed natively in .NET, and directly supporting updategrams as the means to update the database from a DataSet. All if this lead to my original post.