"Banana" Banana@Republic wrote in message
news:4B8B14B3.7010008@Republic...
david wrote:
Banana,

Access/Jet is built on top of the Windows Database primatives.

But what exactly is a 'Windows Database primitives'? I've googled this
phrase and didn't find anything useful. I'd like to know what you mean by
that phrase.

Well, since you ask...

It's like Windows explorer: you never stop to think how it works
any more. But once upon a time, Word Processing was done on
Typewriters, Layout was done on TypeSetters, and databases
were the main reason why commercial computer systems existed.
Even Unix, which in its academic version had no database system,
had built-in database primitives in the version most used inside Bell.

People bought DOS computers and used them for database
systems: the OS primitives which supported this are the
Windows Database Primitives.


DOS had only the most basic database service: read/write/flush
record, and file folders, which were then called directories. The
file folder is the 'Database' unit of DOS-based database systems.

The next important step was the addition of SHARE.EXE,
which added record locking to the file system. Windows 3.x
added a File API which was a thin cover for the DOS file
system, including GET,SET,LOCK, UNLOCK and file
folders.

The next important step was the addition of the Network
Redirector, which was the part of the Network Client which
re-directed File System commands to a Network Server.

The API has changed from Win16 to Win32 to WinNT,
but it has remained backward-compatible to DOS through
the whole change. The data storage system has changed
underneath, but the API has remained backward-compatible.

The Database Primitives than WinXP offers and that are
re-directed to the Server, are still the same database primitives
that DOS offered with SHARE. Create Record. Read Record,
Update Record. Delete Record. Lock Record. Unlock Record.
Missing is FLUSH (required for persistence), indexing, and
transactions. Novell Netware had the missing three: transactions
have finally been added to Windows, but are not yet used by
JET or ACE.

'CRUD' is the basis of all database systems, not just Relational
Database Systems. Create Record, Read-Record, Write-Record,
Lock-Record, Flush, and File Folders were the basis of all DOS
database systems, the systems which were replaced by Access
and SQL Server.

Access was built on top of the OS database primitives, as
were all previous DOS database system. It differed by
including everything inside one file (as SQL Server does).
The code was stored in records in the database. The
queries were stored in records in the database. The
relationships (that is, the table definitions) were stored in
records in the database. And the only way to manipulate
this data was by using the database system. In other words,
it was a very good (for the time and market) implementation
of a Relational Database System.

But the database facilities offered by Access far exceeded
those offered by the OS. Access was not a DOS database
system. It was a system built inside a DOS database
system.

Since that time, the OS has expanded a lot in some
directions, not at all in others.

In particular, DOS and Windows 3.x had no user-level
security. Windows now does have user level security.
Windows Servers now know not only which folders
are shared, but who is allowed access to them.
Windows servers now know not only which records are
locked, but which user and computer has locked them.

If Windows had had user-level security when Access
was first written, Access might have used it. Instead,
Access created its own system of keeping track of which
users and groups had permissions, and which users and
workstation locked records in the database. It did this on
the one hand by using a database of users and groups, and
on the other by using a database of logged-in users and
record locks, which it implements by using OS-level record
locks to lock the Access-level lock records

There used to be some old white papers around which
explained that clearly and with diagrams.

Note, Record locks are not File locks, are not Page locks, are not Sector
locks, are not Cluster locks, because OS-level data records are not sectors,
clusters, files, pages, tables, Access-level records or anything other than
what they a An old OS-level system for data records.

This is all totally transparent to the user, as you would expect.
One of the major aims of computer program development over
the last 40 years has been to isolate function into separate levels
and into separate islands, so that, for example, at the SQL level
you, and your software, shouldn't have to know if you are using
in-process or out-of-process, load-and-go or service, local or
remote, OS or Application. The discussion here has shown just
how successful that effort has been at the user-level.


Anyway, there was a time when creating a new database from
the command line was just as challenging to the average user as
creating a new database from the command line would be to the
average user now. When you would hide your server from the
client tools because a user trying to restore (using RECOVER)
an improperly deleted table (using DEL) would accidently destroy
your whole database. When connect strings like "z:\SALES"
were a foreign language.

We are kind of at that stage with SQL Server now. People
aren't familiar with the browser, or with the commands, or
with the services or with the user interface. They just aren't
familiar. They don't see that underneath it's the same: they
only see the superficial differences.

And , unless you understand what is the same, you aren't
actually going to understand how the differences play out.

That's not the embarrassing ignorance about things like 'ports'
and 'services'.

It's the embarrassing ignorance of 'Access brings the whole
file down',

and it's the more advanced stuff like how SQL Server
can work over a Cisco VPN using Windows security,

and it's the ordinary stuff like understanding that you have
to work with smaller recordsets when using SQL Server.


So the lesson is:

SQL Server is more familiar than you think it is.
It's going to be the superficial differences you notice most.

(david)