No, the code at compile time will insert the begin, end transaction for 
you.  The main questions you have to ask are:

1) What are your programming standards?

Transactions, which are explicitly defined, are better for new 
programmers (new to programming or new to language). Also it is very 
obvious that a transaction is occurring instead of looking at a call to a 
function, which will generate the sql and execute it against the DB.

2) What database are you programming against?

I ask this as when programming against Access V2.0 (scraping the barrel 
now) transactions would actually control the DB as when to write too the 
physical disk.  Need to check what Begin/start end/commit rollback means 
to the actual DB you are coding against.

Hi Mark,
Thanks for this useful info.  The DB I use is SQL Server 2000, and VB.NET 
for the GUI and Data Layer.  I've just looked at the Execution Plan and 
Trace with Query Analyser for an INSERT statement and an UPDATE statement, 
with an without being wrapped in a transaction, and I can't detect any 
difference between them.  So it appears that there certainly is no penalty 
in wrapping single INSERT or UPDATE statements with a transaction to, as 
you rightly say, make it more obvious in the code as to what is going 
on 'under the covers'.