MSSQL (b)locking problem

I just want to clarify the following I obtained from a source. Is this true regarding MSS ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
"When using MSSQL a (b)locking problem can arise. When 1 user locks a row in a table in order to update it, all other users are blocked for this row. If lock escalation isn't turned off, locking can even lead to blocks on page and table level.
Oracle does this differently. When a user updates a row (with lock) than all other users still can read the old row (the consistent database). Only when Oracle is told to commit the data, during this brief period others are blocked (even deadlocks can arise).

On many of the frequently altered tables users are blocked out (even though 'optimistic locking' is used). Indexes can partly solve the problem ."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~

You have the ability to specify the lock type you want to use.

so that would mean:- when the source said "When 1 user locks a row in a table in order to update it, all other users are blocked for this row" is True.

because [ and as I understand] setting adLockOptimistic, will have such an effect as above and the record will 'only be locked' when update is being carried about. Which would mean that as long as the user is updating this record, others stay out...fine with me....but then why is Oracle smarter and letting others still read the record ?

Is the answer : don't compare apples with pears

They are reading the current value of the record when it is pulled. Not the edited/updated values.
When a record is being edited it is locked, so no one else can edit it. If someone requests to read the record before the edit lock is released, they will get the old data, until the lock is released.

Hmmmmm........

You sound logical, and I am beginning to doubt about the stuff that Oracle does.

The only way out would be to see if this really happens on oracle, as stated in the source I quoted from .

nevertheless thanks and we can render this one as a close.

Oracle does have this feature, its called a read-consistent database where changes are made by one user are only visible to that user until committed and written to the actual db file. All other users see a stored version of that data that is held in the RollBack Segments (memory allocated to roll back the sql if not committed or db fails)

What Oracle is doing what MS calls Dirty Reads in SQL. The record is locked and your grabbing data that could be different in the next millisec. Locking is cumbersome in SQL and I really don't like they way the do it. SQL also will create record locks when you are doing a SELECT statement, which just baffles the hell out of me. If your getting a massive amount of hits on your SQL Server that look at the same table/records then you end up with DEAD LOCKS. Microsoft says use (NOLOCK) or the new term (READ UNCOMMITTED), in your SELECT statements to get around this issue, but that only causes an (NOLOCK) Error. This happens if someone is trying to INSERT into the table at the same time someone is doing a SELECT.. Catch 42..

I develop in 14 languages and I work for a company that does all of 7-Eleven's check cashing and help desk. We also have all of Circle-K's check cashing. If your from the US, you know these companies well and know they have a massive amount of data coming in. We are battling it out with Microsoft right now on these kind of SQL issues that just seems like bad design to me.

I have never used Oracle, but have done a lot of research on it.. It costs about 200k, vs the 20k on SQL. They may be a reason for that..