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.
Related
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.
I have gridview, when I connect the sqldatasource and run the application, data from stored procedure is shown but when i switch to design mode, the schema does not loads in gridview. I need that schema to rearrange columns and for formatting purpose.
I never had this problem before, All of sudden it is a problem.
What I tried so far "Refresh Schema" brings up the dialog which list all the parameters I am passing to the storedprocedure. After I changed DBType for every single parameter, it still give me an error, says "check your connection and storedprocedure". While the storedprodure does run, shouldn't it automatically update the schema in gridview. I still have the default 3 columns of gridview.
Note: I may get around the problem by adding each column manually but I am doing this to fix problem in the page, in the first place, dont want to run again in gridview problem. This is a new page that I am building. Thanks
It looks like, Schema is not updated just from StoredProcedure because simple there is not enough information how many columns will be returned.
To work around this issue and sort of quick fix, do the following.
Copy the query from you stored procedure and change the SQLDatasource from stored procedure to Select statement. Run your select statement and finish. Notice that your schema will now be updated.
You can now set your SQLDataSource back to stored procedure and the schema will remain the same.
It also occured to me that when you run a stored procedure, the column names are updated in the query using the name 'Databound col0' 'Databound Col1' and so on
I am not sure sometime it does, sometime it does not. Right click on Gridview and click Referesh Schema does not work as it gives some error.
Along the lines of #hmd, when there is not enough info, especially if there is another perceived dataset being return, i.e you are doing something that returns blank or debug data (rows affected, etc.). A workaround for this is to put "SET NOCOUNT OFF" in the beginning of your procedure and then set it back "ON" again before you return the data. This is also a problem on SSRS.
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
I'm using a DataReader to display informations stored in a table.
I created Two button to go to next record and to go back.
In VB6 I used this code :
While Not Recordset1.EOF
Recordset1.MoveNext
End While
In ASP.NET I didn't find a way to do like it, because DataReader hasn't the EOF property.
EDIT :
While Not Recordset1.BOF
Recordset1.MovePrevious
End While
How can I convert this last code (VB6) to ASP.NET ??
You use Read instead of MoveNext and it'll return false if there aren't any more records.
So:
While rdr.Read()
.... ' process this row
End While
Azirar, ho1 is correct in that you should use a DataTable. If you're updating after every post back and only need a single record you could still use a DataReader, but set up your SQL statement to get a single row (storing the appropriate information needed in your SQL statement (or better yet stored procedure) to get that single record back within query strings or session variables).
I have an application (ASP.NET 3.5) that allows users to rerun a particular process if required. The process inserts records into an MS SQL table. I have the insert in a Try / Catch and ignore the catch if a record already exists (the error in the Title would be valid). This worked perfectly using ADO but after I conveted to LINQ I noticed an interesting thing. If on a re-run of the process there was already records in the table, any new records would be rejected with the same error even though there was no existing record.
The code is as follows:
Dim ins = New tblOutstandingCompletion
With ins
.ControlID = rec.ControlID
.PersonID = rec.peopleID
.RequiredDate = rec.NextDue
.RiskNumber = 0
.recordType = "PC"
.TreatmentID = 0
End With
Try
ldb.tblOutstandingCompletions.InsertOnSubmit(ins)
ldb.SubmitChanges()
Catch ex As Exception
' An attempt to load a duplicate record will fail
End Try
The DataContext for database was set during Page Load .
I resolved the problem by redefining the DataContext before each insert:
ldb = New CaRMSDataContext(sessionHandler.connection.ToString)
Dim ins = New tblOutstandingCompletion
While I have solved the problem I would like to know if anyone can explain it. Without the DataContext redefinition the application works perfectly if there are no duplicate records.
Regards
James
It sounds like the DataContext thinks the record was inserted the first time, so if you don't redefine the context, it rejects the second insert because it "knows" the record is already there. Redefining the context forces it to actually check the database to see if it's there, which it isn't. That's LINQ trying to save a round trip to the database. Creating a new context as you've done forces it to reset what it "knows" about the database.
I had seen a very similar issue in my code were the identity column wasn't an autoincrementing int column, but a GUID with a default value of newguid() - basically LINQ wasn't allowing the database to create the GUID, but inserting Guid.Empty instead, and the second (or later) attempts would (correctly) throw this error.
I ended up ensuring that I generated a new GUID myself during the insert. More details can be seen here: http://www.doodle.co.uk/Blogs/2007/09/18/playing-with-linq-in-winforms.aspx
This allowed me to insert multiple records with the same DataContext.
Also, have you tried calling InsertOnSubmit multiple times (once for each new record) but only calling SubmitChanges once?
gfrizzle seems to be right here...
My code fails with the duplicate key error even though I've just run a stored proc to truncate the table on the database. As far as the data context knows, the previous insertion of a record with the same key is in fact a duplicate key, and an exception is thrown.
The only way that I've found around this is:
db = null;
db = new NNetDataContext();
right after the SubmitChanges() call that executes the previous InsertOnSubmit requests. Seems kind of dumb, but it's the only way that works for me other than redesigning the code.