Just to better understand:
What makes it necessary to use a different login each time you run the test case? Is there something that changes when you login with a user that makes that user no longer valid?
This may be a point in time to talk less about "How do I make DDT do this?" and more about "What do I need to re-architect about my test environment?"
In a "past life", heck, even in my current life, we have tests where we cannot re-use data from one test run to another. Things "Change" with the test data making it no longer valid for an additional test run. So, I have 2 different was that I've done this:
1) Create data "on the fly" - Basically, when I start a test case or test run, the first thing I do is "stage" my test data. I build out any data records, tables, etc. In the past, these were customer data records for doing online ordering of amusement park tickets. I needed to make sure that the customer records were there and didn't have any previous orders associated with them. So, I blanked out the database, started from scratch, and built the data out as a staged "starting" database. I could then run my test run against that starter database, knowing that all my data is EXACTLY how I want it. We even did this as kind of a once a week thing.
Slightly less complicated is what we're doing right now where each test case has built into it the data staging. The first chunk of the keyword tests/script code doesn't actually execute the test case but simply builds the data that I need. The next section of the test case is the actual test, and then I have a "clean up" at the end to dispose of any new data I created so that a re-run of the test case would be starting with a clean slate.
2) Restore from backup - The scenario I mentioned in point 1 above we actually took to another level. We built out the starter database, backed it up out of SQL, and then the first step in any test run is restore the database to SQL so we can start fresh. This made sure that we always had exactly the data we needed to start with. We actually had a whole "test run" that executed once a week that all it did was build out that starter SQL and create the back up so that the rest of the test runs for the week could use "fresh" data.
As Marsha_R said, you can do what you want, but you'll always need to be adding new data into your Excel. I think your best bet is to look into staging data in some way at the start of your test run.
