How to: Can you build a Typed DataSet for a stored procedure w/o using a DataAdapter?

  • Thread starter Thread starter Eric
  • Start date Start date
E

Eric

If you want to create a DataSet, you can drag tables from Server explorer
into it, but not stored procedures. Is there any other way than using a
DataAdapter and calling Generate DataSet to get a typed dataSet that uses
sprocs instead of tables?

p.s. Does anyone know if in VS 2005 you will be able to drag and drop sprocs
onto a DataSet object?
 
Eric said:
If you want to create a DataSet, you can drag tables from Server explorer
into it, but not stored procedures. Is there any other way than using a
DataAdapter and calling Generate DataSet to get a typed dataSet that uses
sprocs instead of tables?
Click to expand...

Yes. It may seem terribly obvious, but use the DataSet designer and just do
it by hand.

If you don't want to do that, write a view which returns the same row type
and drag that into the DataSet designer. I always write views to "publish"
the row type returned by functions and stored procedures.
p.s. Does anyone know if in VS 2005 you will be able to drag and drop
sprocs
onto a DataSet object?
Click to expand...

The problem is that it's difficult to get SqlServer to return table metadata
information from a stored procedure. It tries to run the proc with SET
FMTONLY ON, but it's complicated and unreliable.

David
 
Eric said:
If you want to create a DataSet, you can drag tables from Server explorer
into it, but not stored procedures. Is there any other way than using a
DataAdapter and calling Generate DataSet to get a typed dataSet that uses
sprocs instead of tables?

p.s. Does anyone know if in VS 2005 you will be able to drag and drop
sprocs
onto a DataSet object?
Click to expand...

What?!? I can drag-n-drop sprocs from SQL Server 2000 onto a DataSet just
fine, and it creates the typed dataset with the results the stored procedure
returns along with their data types just as if it were a table. I'm using
VS 2003...what are you using?

Mythran
 
--- Stuff deleted for Brevity
The problem is that it's difficult to get SqlServer to return table metadata
information from a stored procedure. It tries to run the proc with SET
FMTONLY ON, but it's complicated and unreliable.
Click to expand...

Tell me about it. In Crystal Reports, when you attempt to set the
DataSource.Location Property of a report in code, if it's a sproc, it
actually executes the sproc in question whereas if it's a table it makes
some quick system calls to get metadata. I dont even think SET FMTONLY ON
was used. For a report against a giant database that was.....problematic,
especially if there were multiple tables in the report.
 
Back
Top