Hello Maya,

> >>Locking issues? Do you expect multiple people to run the same
> >>UPDATE statement against the record?
>
> Nope, I was worried about: (pseudo code)
>
> a- Start Transaction
> b- update StockTable small fields
> c- if New-Image-Selected then
> update same StockTable record's blob field (in a separate SQL
> statement)
> d- Commit
>
> I think line c- will create a lock conflict as the same record is being
> updated twice within the same transaction?

A quick test revealed this shouldn't be a problem.

> (And merging it into one update is not going to be easy as I have a
> middle layer that constructs the update SQL automagically, so I'd rather
> try to not have to go that route if at all possible)
>
> >>SELECT * FROM ... is a big no-no. Better get that fixed :-)
> OK, so agreed, your DB design shouldn't try to compensate for bad SQL,
> but regarding the update issue, good or bad idea?

See above.

> Or, in your experience, is the speed of updating say a 1MB image in a
> blob negligible?

Don't update the blob if you don't have to.

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com