I am working on a project where I do not have any control over the versions of products that I have been asked to work with.
I am building an ASP.NET user control. Data is retrieved via SqlDataSource controls working against Firebired 2.0 databases. Everything was fine until I needed to populate one of the SqlDataSource controls via a stored procedure rather than a SELECT statement.
I have verified that the procedure is returning data in EMS SQL Manager for Interbase and Firebird. However, when I set the SqlDataSource's SelectCommand property to EXECUTE PROCEDURE myProc and call Select(), I am getting no data.
My procedure takes no input parameters so it seems to me that it should be straight-forward.
The reality of the situation is that I could use a simple SELECT statement if I were able to move to even 2.1 as I would have access to the List() aggregate function, but that is not a possibility.
Does anyone have any experience trying to do this? Does the procedure call need to be modified in any way? Any help would be greatly appreciated.
If it is selectable stored procedure (it has SUSPEND command in it) then you should call it with SELECT statement, not with EXECUTE PROCEDURE statement. So set your SelectCommand to
SELECT * FROM spName
and it should work.
I would normally do this like so (against SQL Server) :
// set the SqlDataSource's SelectCommand to the *name* of the stored procedure
myDataSource.SelectCommand = "myProc";
// tell the SqlDataSource that this is a *stored procedure* now
myDataSource.SelectCommandType = CommandType.StoredProcedure;
Since your stored procedure takes no input parameters at all, this should really be all!
With SQL Server, selecting the data works just fine with this setup.
Related
I can run the 'guts' of my stored procedure as a giant query.. just fine from SQL Management Studio. Furthermore, I can even right click and 'execute' the stored procedure - .. y'know.. run it as a stored procedure - from SQL Management Studio.
When my ASP.NET MVC app goes to run this stored procedure, I get issues..
System.Data.SqlClient.SqlException: Invalid object name '#AllActiveOrders'.
Does the impersonation account that ASP.NET runs under need special permissions? That can't be it.. even when I run it locally from my Visual Studio (under my login account) I also get the temp table error message.
EDIT: Furthermore, it seems to work fine when called from one ASP.NET app (which is using a WCF service / ADO.NET to call the stored procedure) but does not work from a different ASP.NET app (which calls the stored proc directly using ADO.NET)
FURTHERMORE: The MVC app that doesn't crash, does pass in some parameters to the stored procedure, while the crashing app runs the Stored Proc with default parameters (doesn't pass any in). FWIW - when I run the stored procedure in SQL Mgt. Studio, it's with default parameters (and it doesn't crash).
If it's of any worth, I did have to fix a 'String or Binary data would be truncated' issue just prior to this situation. I went into this massive query and fixed the temptable definition (a different one) that I knew to be the problem (since I had just edited it a day or so ago). I was able to see the 'String/Binary truncation' issue in SQL Mgt. Studio / as well as resolve the issue in SQL Mgt Studio.. but, I'm really stumped as to why I cannot see the 'Invalid Object name' issue in SQL Mgt. Studio
Stored procedures and temp tables generally don't mix well with strongly typed implementations of database objects (ado, datasets, I'm sure there's others).
If you change your #temp table to a #variable table that should fix your issue.
(Apparently) this works in some cases:
IF 1=0 BEGIN
SET FMTONLY OFF
END
Although according to http://msdn.microsoft.com/en-us/library/ms173839.aspx, the functionality is considered deprecated.
An example on how to change from temp table to var table would be like:
create table #tempTable (id int, someVal varchar(50))
to:
declare #tempTable table (id int, someval varchar(50))
There are a few differences between temp and var tables you should consider:
What's the difference between a temp table and table variable in SQL Server?
When should I use a table variable vs temporary table in sql server?
Ok. Figured it out with the help of my colleague who did some better Google-fu than I had done prior..
First, we CAN indeed make SQL Management Studio puke on my stored procedure by adding the FMTONLY option:
SET FMTONLY ON;
EXEC [dbo].[My_MassiveStackOfSubQueriesToProduceADigestDataSet]
GO
Now, on to my two competing ASP.NET applications... why one of them worked and one of them didn't? Under the covers, both essentially used an ADO.NET System.Data.SqlClient.SqlDataAdapter to go get the data and each performed a .Fill(DataSet1)
However, the one that was crashing was trying to get the schema in advanced of the data, instead of just deriving the schema after the fact.. so, it was this line of code that was killing it:
da.FillSchema(DataSet1, SchemaType.Mapped)
If you're struggling with this same issue that I've had, you may have come across forums like this from MSDN which are all over the internets - which explain the details of what's going on quite adequately. It had just never occurred to me that when I called "FillSchema" that I was essentially tripping over this same issue.
Now I know!!!
Following on from bkwdesign's answer about finding the problem was due to ADO.NET DataAdapter.FillSchema using SET FMTONLY ON, I had a similar problem. This is how I dealt with it:
I found the simplest solution was to short-circuit the stored proc, returning a dummy recordset FillSchema could use. So at the top of the stored proc I added something like:
IF 1 = 0
BEGIN;
SELECT CAST(0 as INT) AS ID,
CAST(NULL AS VARCHAR(10)) AS SomTextCol,
...;
RETURN 0;
END;
The columns of the select statement are identical in name, data type and order to the schema of the recordset that will be returned from the stored proc when it executes normally.
The RETURN ensures that FillSchema doesn't look at the rest of the stored proc, and so avoids problems with temp tables.
I'm calling a stored procedure to generate an ADO recordset and I'd like to be able to update the data before outputting it (but not write those updates back to the DB).
Is this even possible and if so, how?
I've tried a number of cursor and lock types but they either error out immediately or when I try to update a recordset field.
io_oRecordSet.CursorLocation = adUseClient
io_oRecordSet.Open oDataCmd, , adOpenStatic, adLockOptimistic, adCmdStoredProc
... iterate through RS ...
io_oRecordSet("myCol").value = "foo"
This one generate the following error
Microsoft Cursor Engine error '80040e21'
Multiple-step operation generated errors. Check each status value.
From what I've seen I suspect that ADO might not like that the data is coming from a stored procedure since it wouldn't know how to do a DB update.
If you absolutely don't need to update the database, you can use a disconnected Recordset. Just make sure you use a client-side cursor and set the Recordset's ActiveConnection property to Nothing after you open it.
I've recently started working in ASP.NET and RDBMS.I'm making a test form where I can do basic add,update,delete operations.I'm using OracleDataClient to do the DB operations.I was able to populate a listbox using OracleDataAdapter.
Now after clicking on update button,I intend to Update in DB.I've Dataadapter with it's update property.But the update query is not happening.The examples I saw over net all have Select command before Update.Is it actually like that or am I missing some point.
How does Oracle DataClient work with Insert,Update,Delete Commands.
keep it in datalist or temporary table like data table or Hash table....display data in datalist and for update operation use (1)the proper query (2) command Behaviour (3) check the connection and Dml command operation (4) CommandBehavior
I am debugging code written by a previous developer :-)
I have a SQLDataSource control that is calling a database stored procedure, and passing quite a large number of paramaters, and the stored proc returns records that populates a gridview control.
When I walk through the code behind to determine the values being passed, is there any way that I can see exactly how the parameters are being formated and passed to the stored proc?
You can use SqlDataSource's Updating event for this. It's parameter SqlDataSourceCommandEventArgs has a property Command that contains the parameters for the query.
Instead of trying to unpick them from Code-behind, use Sql Profiler. If you are using the Express version, there's a Profiler for that too: AnjLab Sql Profiler
The short version:
I have a grid view bound to a data source which has a SelectCommand with a left join in it because the FK can be null. On Update I want to create a record in the FK table if the FK is null and then update the parent table with the new records ID. Is this possible to do with just SqlDataSources?
The detailed version:
I have two tables: Company and Address. The column Company.AddressId can be null. On my ascx page I am using a SqlDataSource to select a left join of company and address and a GridView to display the results. By having my UpdateCommand and DeleteCommand of the SqlDataSource execute two statements separated by a semi-colon I am able to use the GridView's Edit and Delete functionality to update both table simultaneously.
The problem I have is when the Company.AddressId is null. What I need to have happen is have the data source create a record in the Address table and then update the Company table with the new Address.ID then proceed with the update as usual. I would like to do this with just data sources if possible for consistency/simplicity sake. Is it possible to have my data source do this, or perhaps add a second data source to the page to handle some of this?
Once I have that working I can probably figure out how to make it work with the InsertCommand as well but if you are on a roll and have an answer for how to make that fly as well feel free to provide it.
Thanks.
execute two statements separated by a
semi-colon
I don't see any reason why it wouldn't be possible to do both an INSERT and UPDATE in two statements with SqlDataSource just like you are doing here.
However, just so you know, if you have a lot of traffic or users using the application at the same time, you can run into concurrently issues where one user does something that affects another user and unexpected results can cascade and mess up your data. In general, for things like what you are doing - INSERT and UPDATE involving primary or foreign keys, usually SQL TRANSACTIONs are used. But, you must execute them as SQL stored procedures (or functions), on your SQL database. You are still able to call them from your SqlDataSource however by simply telling it that you are calling a stored procedure.