First of all, direct answer to your specific question: take a look at DDE, this can cause the VB form to change almost anything at runtime.
However, I have a better answer for you:
Odds are the VB client app is not using an encrypted protocol (such as SSL) - you can just intercept the network communications, and alter it on the wire. Or, just craft your own messages and send them to the server yourself. It's a bit fiddly, but not too difficult. Or just use something like OllyDbg to grab the data before it goes down to the wires.
(Btw, either way, even if they do encrypt the channel you should be able to get around that, since its encrypted on your client. It is a bit trickier, but still not too difficult. And if you go for OllyDbg the channel encryption is irrelevant.)
In this way it will be possible to perform your SQL Injection, and not even too difficult.
Now, I have an even better answer for you - don't even bother with SQL Injection.
It is very likely, given the simplistic architecture that was common back in VB6 apps, that your client app talks directly to the database. (On the off chance that there is an intermediate server app, this part won't help you).
If that's the case, that means that somewhere in the client app (possibly hardcoded), there are credentials to access the database directly. (If you can't find them, grab them using the previous techniques).
Once you have these credentials - just go directly to the database, using the database vendor's management tool, and have your way with it. The app does not need to be in your way at all.
Not only can you do anything you want with the data and tables, there will be no way to trace this back to you. In fact, it's highly unlikely that it will be possible to prove that anyone did anything wrong... (well, except for the missing data...)