Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
tfountain
Constraint Violating Yak Guru
491 Posts |
 Posted - 2003-03-21 : 14:44:10
|
| This is more of an ADO question but since it's a SQLOLEDB extended property I figured a guru or two would know the answer here ;). Ok, my problem is I have a stored procedure that derives two values (Email, DisplayName) from one of three other tables. The base table itself contains these columns but they're only for system purposes and are self maintained via triggers from the other tables. I'm writing a method that performs a batch update on disconnected recordset in VB6 on these columns. But since the columns returned in the stored procedure don't have a base column I can't update them. Is there a way to programmatically tell ADO the change the base column using the extended properties? I'm using MDAC 2.6. |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2003-03-21 : 23:56:07
|
| No, you can only manipulate the columns of a recordset that are returned in the recordset, and IIRC you can't even do that unless the source is a base table or updateable view, never a stored procedure. If you are hitting the table directly then you'll either have to include the columns in the recordset's data source, or use the existing columns as a guide for a Command object to run code to update the hidden columns in the table. The Command object would execute code outside of the BatchUpdate method though, so it will likely break any kind of transactional integrity you may need to keep during the batch.While I love BatchUpdate, this kind of situation works against it, and you might as well perform all of the update operations using a Command object. You can have it call a stored procedure that takes all of the necessary values and updates the proper tables with them. It's too messy to combine an ADO recordset Update method with a Command object, especially against the same data source(s). |
 |
|
|
tfountain
Constraint Violating Yak Guru
491 Posts |
Posted - 2003-03-24 : 11:31:16
|
| I ended up adding additional columns in the view from the source table. As far as using a procedure to be the source of a batch update, it works fine for me, and this isn't the first time I've done this. There must be differences in how we are implementing the batch updates within a transaction. |
|
|
|
|
|
|
|
|
BASECOLUMNNAME question