Discouraged About Timestamps

I have read the forums and fail to be encouraged about using the timestamp to handle concurrency.  I have SQL 2005 and am using the DataReader and command objects for data manipulation.  The database has about a dozen related tables to each other in some way.  Correct me if I am wrong, but using timestamps means I must store each table's original rowversion at read time in several possible combinations of variables (based on the joined tables at the time of read).  Is this right?  Then at update time, what if some related tables are timestamped with the original value and others have changed since read time?  How would each update stored procedure know which other dependent tables were fetched at read time?  It's easy to corrupt the data this way.

SELECT s.OrderNumber, a.UserName AS OrderedBy, cn.LastName + ', ' + cn.FirstName AS ContactName, s.CarbonCopy, s.Application, s.OrderDate,

s.FollowUpDate, s.ProdStartDate, s.InternalNote, s.SampleNote, s.UpdatedBy, s.DateLastUpdated, cn.EMail AS ContactEmail, s.MfgID,

co.CompanyName, s.ShipVia, cn2.LastName + ', ' + cn2.FirstName AS ContactName2, co2.CompanyName AS Expr1,

cn3.LastName + ', ' + cn3.FirstName AS ContactName3, s.MfgContactID, s.DistributorID, s.DistContactID, s.CustomerContactID,

s.VersionStamp, a.VersionStamp, cn.VersionStamp, co.VersionStamp, cn3.VersionStamp    <-------  Is all this really necessary?

FROM Samples AS s LEFT OUTER JOIN

Associates AS a ON s.OrderedByID = a.AssociateID LEFT OUTER JOIN

Contacts AS cn ON s.CustomerContactID = cn.ContactID INNER JOIN

Companies AS co ON s.MfgID = co.CompanyID LEFT OUTER JOIN

Contacts AS cn3 ON s.DistContactID = cn3.ContactID LEFT OUTER JOIN

Contacts AS cn2 ON s.MfgContactID = cn2.ContactID LEFT OUTER JOIN

Companies AS co2 ON s.DistributorID = co2.CompanyID

WHERE (s.SampleID = @SampleID)

What would be a simple way to update a table that depends on other tables having original version stamps?  Then at runtime how would I enforce it without generating violations when the users were updating, say, the Samples table and just viewing the dependent tables' columns, not changing them.