Ted Dawson wrote:
Yes it is broken, but you can use a Recordset to do the same thing, just
remove the last piece of code that closes the recordset.
You're going to have to show me how to do this... failing to close a
recordset can't possibly add a new row to the table, or update or delete any
rows. Will you please document this for me?
I always use Stored Procedures for my inserts, deletes and updates. So I
create a new Recordset, name it, browse to the stored procedure, enter
the first parameter, save it, open it again (cos there is a bug that
only lets you enter the first parameter the first time you do this),
then enter the other parameters. Now go into the code, make sure that
each parameter has the correct length, otherwise you will lose data
during the process. Go to the end of the page and delete the code that
closes the recordset object. Only do this if you stored procedure
doesn't also return a recordset.
If you don't use stored procedures I guess its going to be different,
but I don't let the SQL user that my pages use have direct access to the
tables, the stored procedures have execute permissions for the user, so
in case of any sql injection the attacker never has read access to any
tables. They would only have access to the stored procedures that don't
use dynamic sql.
Any questions let me know.
How To Ask Smart Questions