Compiler Bug??

[Shaggy Hiker]

Found a few compiler bugs in VB6. This looks like one in .NET, but I might just have been too lazy to track down the minutiae that allow it. Here it is:

I sent an XML file across a TCP connection from a PDA (ok, that's my acronym quota for the day). The file came through fine, and was read fine. The file contained Table1 and Table2.

The routine took each record from Table1, did some minor manipulation, then stuck it into an Access database. This worked fine.

The routine then took each record from Table2, did some different manipulation, then stuck it into a different table in the same database. I fought with this ******* for hours. I was using a simple INSERT INTO statement to move the records, and supplying the parameters using:

table.Rows(x).Item("ItemName")

In debugging, I could see that the item being returned was indeed the correct item. The query was fine, as well. I have written plenty of those, but just to be sure, I copied an old one (I got bloody desperate over this).

Finally, I removed all the required constraints from the database, so the query stuffed any old data into the record. Lo and behold, what was actually being written was not the data being passed into the parameters, but was actually the data from the single record in Table1.

Therefore, is there any reason why this should happen?

The SQL string was an INSERT INTO TableDest ([fields]) VALUES ([?,?,...]), which always worked for me before.

The parameters were put added like this:

cmd.Parameters.Add("[FieldName]",Table2.Rows(x).Item("[FieldName]")

Note: The names have been changed, and anything in brackets is just a placeholder in this example, but the format is correct.

However, when the command was executed, what was actually written into the table (the correct table, by the way) was not the values passed into the parameters, but the values from the first row in Table1.

I could not force the thing to actually look at table2. I cleared the table, and re-created it, but all that did was double the number of rows found in Table2.

My eventual solution, ugly as it is, is to dispose of the command after writing each line, and create a new command for the next line.

Is this a bug?

[PT Exorcist]

I doubt its a bug. Check better the code...

[Shaggy Hiker]

Checked, re-wrote, cussed extensively. Nothing worked

Perhaps somebody knows something about an ADO command that I am unaware of.

If you set command.CommandText to some SQL statement, then call

Command.ExecuteNoQuery (or whatever that is)\

Then set CommandText to a different SQL statement, and do another ExecuteWhatever, is thre a problem with this?

[hellswraith]

Please post the most simplest of code you have that is producing this error. My guess is it is the code as well.

[Shaggy Hiker]

Damn, already scrapped it and worked around it. I was hoping the description was sufficient.

In general, it is the code, but I have had the great pleasure of reporting several bugs to Microsoft in VB6, while .NET would be newer, and there could be more.

To reproduce this will take some effort, but I may get to it this weekend. In short:

1 A dataset with two tables.

2 do something with the rows in table1 (doesn't much matter what)

3 INSERT the rows from table2 using the same command object used in step 2, but with a different SQL string that takes the values as parameters.

4 Regardless of whether the parameters are correct, what is written is the data from table1.

If you should never re-use a command object, then it is my problem. Otherwise, there is no excuse for this.

I'll see if I can re-create it in simplified form.