DataSet has no fields

Please Help. I am calling a stored procedure which creates a SQL statement and
then runs
exec (@.SQL + @.Where + @.Order)
Is there anyway to manual create fields. The Stored procedures returns the
same column names and number of columns?
--
Thanks,
Jon AWhy don't you set the proc to just do a select of the fields you want until
the report is built, then change the proc back to the exec(string) command.
That way you'll have access to the fields in the builder.
"Jon A" wrote:
> Please Help. I am calling a stored procedure which creates a SQL statement and
> then runs
> exec (@.SQL + @.Where + @.Order)
> Is there anyway to manual create fields. The Stored procedures returns the
> same column names and number of columns?
> --
> Thanks,
> Jon A|||Alternatively, you can go into the properties of the dataset that you want
fields for (by clicking the elipsis next to the name of the dataset on the
Data tab in report design) and go to the "Fields" tab. Here you can define
your fields manually and this will enable you to use them in your report
design. Be careful to name your fields exactly as they are returned from the
database otherwise RS will run into problems.
Also, another thing to try is to click on the "Refresh Fields" button on the
Data tab in report design. This executes the query and "figures out" what
fields are returned where it may not be immediately obvious from your query
design (especially where using Dynamic SQL is concerned).
Cheers
--
Tim McOwan
"Mary Bray [SQL Server MVP]" wrote:
> Why don't you set the proc to just do a select of the fields you want until
> the report is built, then change the proc back to the exec(string) command.
> That way you'll have access to the fields in the builder.
> "Jon A" wrote:
> > Please Help. I am calling a stored procedure which creates a SQL statement and
> > then runs
> > exec (@.SQL + @.Where + @.Order)
> > Is there anyway to manual create fields. The Stored procedures returns the
> > same column names and number of columns?
> >
> > --
> > Thanks,
> > Jon Asql

DatabaseLog table

AdventureWorks database has tables: DatabaseLog, ErrorLog. I figured there should be a system stored procedure that creates such tables for your database. So far I could not find what it is. I would appreciate a pointer.

Thanks.

hi,

AlexBB wrote:

AdventureWorks database has tables: DatabaseLog, ErrorLog. I figured there should be a system stored procedure that creates such tables for your database. So far I could not find what it is. I would appreciate a pointer.

Thanks.

those tables are not system table but user tables...

dbo.ErrorLog has a dependency chain including dbo.uspLogError stored procedure, 9 triggers and more 3 stored procedures, HumanResources.uspUpdateEmployeeInfo, HumanResources.uspUpdateEmployeeLogin and HumanResources.uspEmployeePersonalInfo, while dbo.DatabaseLog is referenced by a database trigger, ddlDatabaseTriggerLog...

regards

|||

Andrea Montanari wrote:

hi,

AlexBB wrote:

AdventureWorks database has tables: DatabaseLog, ErrorLog. I figured there should be a system stored procedure that creates such tables for your database. So far I could not find what it is. I would appreciate a pointer.

Thanks.

those tables are not system table but user tables...

dbo.ErrorLog has a dependency chain including dbo.uspLogError stored procedure, 9 triggers and more 3 stored procedures, HumanResources.uspUpdateEmployeeInfo, HumanResources.uspUpdateEmployeeLogin and HumanResources.uspEmployeePersonalInfo, while dbo.DatabaseLog is referenced by a database trigger, ddlDatabaseTriggerLog...

regards

Andrea, I never doubted that those tables are user tables. I've never said otherwise.

My question was "how to set up a log table for an arbitrary user database?"

|||As far as I can remember those tables, these are just tables for a generic error solution in SQL Server 2005 which can be download as a sample at the MSDN sites.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de|||

hi,

Jens is right about the "general logging" purpose...

if you like you can script those objects out... try having a look at my amScript free project, that can script out even the database trigger so that you can inspect the relative DDL code..

regards

|||

Andrea Montanari wrote:

hi,

Jens is right about the "general logging" purpose...

if you like you can script those objects out... try having a look at my amScript free project, that can script out even the database trigger so that you can inspect the relative DDL code..

regards

Thank you, Andrea and Jens. Andrea's websites are very helpful. I have already downloaded some code.