DDT iterating

DDT currently does not have a reset.  It creates forward-only cursors on the record set.  In order to "restart" a DDT object, you need to, essentially, close and destroy the object and recreate it to re-iterate.

Ok. Thanks.

I'm actually a little curious, thought.  You're the second person to ask about restarting a DDT iteration.  Can I ask how you're using the DDT driver object where you have a need to restart?  It's possible you can still use a single instance of the DDT object and just implement it's usage a bit differently to eliminate the need for a restart.

First note that the grids and databases are not supported by checkpoints within Test Complete. I could not use them anyway because of the variation within the expected result.



I have an action that my AUT performs. I use DDT to connect to the database and create a table variable. In order to set the table variable's RowCount property to ensure enough rows to hold my data, I iterate through DDT Driver once to count rows. I then have to iterate through again to populate the columns in the table variable from ddt.



My test then performs some actions. I open another DDT Driver object to compare the data against the expected results and the original values stored in the table variable.



I have done this in a few parametrized procedures so I can do this across a bunch of actions in my AUT thereby confirming that they are acting on the data as expected. 



If you know of a better way to do this, feel free to let me know!



Thanks



S

Is there anything that prevents me from creating ADO connection and recordset objects directly to do this? No there really isn't is there?

Have you considered getting the rowcount from your database using a simple SQL query for count(*)?  That will return the rowcount and you can just assigned that to your table variable.  Then you only need to iterate through your DDT object once to populate the table.



And no... using ADO objects or simply Sys.OleObject("ADODB.Connection") can work, too.



For that matter, IIRC, if you create a DDT.ADODriver object, it's a static object, not dynamic.  So, even if the data changes after the fact, it should still contain your "original" values.  If you create another DDT.ADODriver object later after the test has been run, it will contain your new data.  You should be able to just contain the values.

With a DDT driver? I would have to create a View in the db would I not? Can one use a SQL String in place of a table/view name in ddt driver object creation?

I would create an ADODB.Connection and run a quick SQL query to return the count as a string.  

Robert says: "For that matter, IIRC, if you create a DDT.ADODriver object, it's a
static object, not dynamic.  So, even if the data changes after the
fact, it should still contain your "original" values."



Yes I considered doing that. If I created a static ado recordset, I could do the same thing. But I was concerned about the recordset / ddt driver "should" still contain my original values. This is a high risk area of the system. I have done no third party software validation on ADO (OMG I so don't want to do that), so I decided this little extra bit is not too burdensome.



Thanks for your help!

Yes Robert, I agree. That would be faster. I will do that. Thanks for your thoughts.