"Kay" <y...@somehost.somedomain> wrote in message
news:GID2b.559$yJ3.1...@news.uswest.net...
MS Access is an end-user query tool. Jet is not even close to a relational
database management system. Jet is a rather primitive file processor.
Depends on your level of education and how anal you are.
I think the answer depends more on the definition of "relational database
system". If you mean that it conforms to the rules of relational database
theory as laid down by EF Codd, and that the primary method of data access
and manipulation is through structured query language then yes, by this
definition, Jet, (not Access, which is just a front-end), is "relational".
However, the term "relational database" also defines a data access
methodology, to which Jet does not conform. Jet uses an ISAM data access
technique.
Yes, of course!
What makes you think it wouldn't be one?
SQL Server is Microsofts relational database product, Access is just a
cheesy rude hack, that they threw in with the word processor.
Its just an end user product, that in some way emulates a relational
database. Indeed it can in some situations even be used as a
relational database.
No. It depends on left to right evaluation of code, the DISTINCTROW
clearly shows that it does not use tables, pivots are reports and not
queries, forms are not part of an RDBMS, and it does not conform to
Standard SQL.
It is an application development tool built around an indexed file
system with a front end that looks like (but does not work like) SQL.
Yes. I would also call CPM an operating system, because it is an operating
system. Whether it is a good operating system is a different matter.
> SQL Server is Microsofts relational database product, Access is just a
> cheesy rude hack, that they threw in with the word processor.
>
> Its just an end user product, that in some way emulates a relational
> database.
Jet is a file processor, which allows one to process files as databases.
Access is an end-user query tool that doesn't emulate anything. Neither of
them is an rdbms.
> Indeed it can in some situations even be used as a
> relational database.
Do you understand the difference between a database and a dbms? Or are you
just sloppy?
The fact that is an end-user query tool and not a database management
system. What makes you think it would be one?
>"Kurt Häusler" <use...@fub-group.de> wrote in message
>news:4qumkv8u9j8fa7kdn...@4ax.com...
>> Heh. Would you call Windows 98 an operating system?
>
>Yes. I would also call CPM an operating system, because it is an operating
>system. Whether it is a good operating system is a different matter.
Yes I would also call CP/M an operating system, even DOS. However the
X-Window system I would not call an operating system, and for that
reason DOS shells like windows 98 are also not operating systems
>
>> SQL Server is Microsofts relational database product, Access is just a
>> cheesy rude hack, that they threw in with the word processor.
>>
>> Its just an end user product, that in some way emulates a relational
>> database.
>
>Jet is a file processor, which allows one to process files as databases.
>Access is an end-user query tool that doesn't emulate anything. Neither of
>them is an rdbms.
From Webster's Revised Unabridged Dictionary (1913) :
Emulate \Em"u*late\, v. t. [imp. & p. p. Emulated; p. pr. &
vb. n. Emulating.]
To strive to equal or to excel in qualities or actions; to
imitate, with a view to equal or to outdo, to vie with; to
rival; as, to emulate the good and the great.
Thine eye would emulate the diamond. --Shak.
Access emulates a rdms by advertising itself as one, and appearing as
one on the outside even though its not on the inside.
>
>> Indeed it can in some situations even be used as a
>> relational database.
>
>Do you understand the difference between a database and a dbms? Or are you
>just sloppy?
Sure, I understand the difference, and I would usually make a rigid
distinction between the two, but this is a windows world newsgroup,
where everything is switched. What was once a graphical shell is now
an operating system, what was once called litigation is now called
innovation, and what was once called user expectation has now been
discarded entirely as a concept.
I am sloppy, because if I started programming on windows straight out
of the unix world, or the university world, with the rigid formal
methods that work there, I would have killed myself within the first
day.
One really has to discard everything that one considers good style and
practice, and adopt the "try this", "run it", "debug it", "repeat"
style of software development.
A non-sloppy guy trying to fit into the sloppy world of microsoft.
That brings up an interesting question. Is Windows 98 a graphical shell on a
dos operating system? Or is the command prompt a dos command shell on a
Windows 98 operating system?
The product called Windows 98 is an operating system bundled with both a
graphical shell and a command shell. If not, what product did you buy to get
the operating system?
> >> SQL Server is Microsofts relational database product, Access is just a
> >> cheesy rude hack, that they threw in with the word processor.
> >>
> >> Its just an end user product, that in some way emulates a relational
> >> database.
> >
> >Jet is a file processor, which allows one to process files as databases.
> >Access is an end-user query tool that doesn't emulate anything. Neither
of
> >them is an rdbms.
>
> From Webster's Revised Unabridged Dictionary (1913) :
>
> Emulate \Em"u*late\, v. t. [imp. & p. p. Emulated; p. pr. &
> vb. n. Emulating.]
> To strive to equal or to excel in qualities or actions; to
> imitate, with a view to equal or to outdo, to vie with; to
> rival; as, to emulate the good and the great.
>
> Thine eye would emulate the diamond. --Shak.
>
> Access emulates a rdms by advertising itself as one, and appearing as
> one on the outside even though its not on the inside.
Microsoft may advertise Access as an rdbms, but the product does not strive
to equal or to excel in any of the qualities of an rdbms. Microsoft simply
relies on the ignorance of consumers in its advertisements.
As I said, Access does not emulate anything. It is an end-user query tool.
> >> Indeed it can in some situations even be used as a
> >> relational database.
> >
> >Do you understand the difference between a database and a dbms? Or are
you
> >just sloppy?
>
> Sure, I understand the difference, and I would usually make a rigid
> distinction between the two, but this is a windows world newsgroup,
> where everything is switched.
comp.databases is a windows world newsgroup? Whatever that is?
> What was once a graphical shell is now
> an operating system
The product called Windows 98 was never a graphical shell. That product has
always been an operating system bundled with both a graphical shell and a
command shell. Windows 2.0 was a graphical shell, but that is a completely
different product.
> what was once called litigation is now called
> innovation
Not by an intelligent and informed public. Not any more than an end-user
query tool is called an rdbms by an intelligent and informed public.
> and what was once called user expectation has now been
> discarded entirely as a concept.
One may ignore a concept without discarding the concept. Users have not
discarded their expectations.
> I am sloppy, because if I started programming on windows straight out
> of the unix world, or the university world, with the rigid formal
> methods that work there, I would have killed myself within the first
> day.
If you are saying that your sloppiness is a psychological defense against
your own suicidal tendencies, I say have done with it and don't burden us
with it.
> One really has to discard everything that one considers good style and
> practice, and adopt the "try this", "run it", "debug it", "repeat"
> style of software development.
No, one doesn't. One can just have psychological balance instead.
> A non-sloppy guy trying to fit into the sloppy world of microsoft.
Try harder.
If you are asking if the database engine that also ships on the office cd is
relational, then the answer is yes, that engine is a relational database.
--
Albert D. Kallal (ms-access MVP)
Edmonton, Alberta Canada
kal...@msn.com
http://www.attcanada.net/~kallal.msn
I haven't used Access for a while, but you could ask alternative
questions :
- does it allow duplicate rows in its tables ?
- does it allow nulls in its columns ?
If the answer to either is "yes", then it doesn't deal with relations,
therefore can't be a relational database management system. It might
still qualify as an SQL DBMS, though. Like I say, I haven't used
Access since 2.0.
- Tony
>y...@somehost.somedomain (Kay) wrote in message news:<GID2b.559$yJ3.1...@news.uswest.net>...
>> Would you call MS Access a relational database system?
>
>I haven't used Access for a while, but you could ask alternative
>questions :
>- does it allow duplicate rows in its tables ?
If you let it.
>- does it allow nulls in its columns ?
If you let it.
>If the answer to either is "yes", then it doesn't deal with relations,
>therefore can't be a relational database management system. It might
>still qualify as an SQL DBMS, though. Like I say, I haven't used
>Access since 2.0.
Access (and Jet) gets a hard time in some circles, sure it's not in
the same league as SQL Server, Oracle, Sybase, DB/2, etc but for what
it is it's a good product. The trouble is that it's so easily
available (pre-installed on your new PC?) and cheap and easy to use
that any idiot can make a database in it, unfortunately many do.
If a complete numpty went out and bought SQL Server and produced a
database that broke most relational rules in the book, repeating
groups, no primary keys, no foreign keys, no unique indices, etc,
would that be a reflection on the product or on the person designing
the database? Ask anyone and they'l point straight at numpty, if he
did the same thing with Access, they'd point at the product.
--
Ride Free (but you still have to pay for the petrol)
(replace sithlord with trevor for email)
"Bob Badour" <bba...@golden.net> wrote in message news:<PpK2b.948$p32.85...@mantis.golden.net>...
By this definition then, Oracle is not an rdbms. <shrug>
--
Tim - http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Want some?" - Ditto
"Kay" <y...@somehost.somedomain> wrote in message
news:GID2b.559$yJ3.1...@news.uswest.net...
Microsoft doesn't say so...
<http://www.microsoft.com/office/access/default.asp>
Search for the word "relational." Not there.
They are presenting at least some degree of "honesty in advertising"
in this...
--
(reverse (concatenate 'string "gro.gultn" "@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/linuxxian.html
"Fear leads to anger. Anger leads to hate. Hate leads to using Windows
NT for mission-critical applications." --- What Yoda *meant* to say
Access doesn't have tables or columns. Jet has tables of sorts as does
SqlServer.
Sigh...
As usual, black-and-white definitions don't work.
Access will, or will not, allow duplicate rows in a table, depending on
how the table is defined.
Access will, or will not, allow nulls in its columns, depending on how
the column is defined.
>After a long battle with technology,y...@somehost.somedomain (Kay), an earthling, wrote:
>> Would you call MS Access a relational database system?
>
>Microsoft doesn't say so...
><http://www.microsoft.com/office/access/default.asp>
>
>Search for the word "relational." Not there.
'tis on this one http://www.microsoft.com/office/using/column06.asp
>They are presenting at least some degree of "honesty in advertising"
>in this...
Try http://www.fordvehicles.com/cars/focus/
Can you spot the word "seats"? Must be standing room only in that car
then.
That's not where they are marketing the strengths and characteristics
of Access.
If it were a relational database, and this were of any practical
importance to either they or the customers they want to have, then it
would make sense for them to use the word somewhere in the main page
of marketing. _Reality_ is that most of the people targeted by their
marketing for Access likely wouldn't know a "normalized form" if it
bit them on the butt.
>>They are presenting at least some degree of "honesty in advertising"
>>in this...
>
> Try http://www.fordvehicles.com/cars/focus/
>
> Can you spot the word "seats"? Must be standing room only in that car
> then.
It goes without saying that cars have seats.
There are numerous database systems sold that are unquestionably not
relational.
Not only because a vendor is merely playing "games of pretense of
honesty," as seems to be too often the case, but often enough because
the system really and truly is totally "unrelational." Sleepycat DB
is certainly NOT relational. Poet is NOT relational. Ditto for
numerous other "object databases" and "embedded databases."
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','ntlug.org').
http://www.ntlug.org/~cbbrowne/nonrdbms.html
One last point about metaphor, poetry, etc. As an example to
illustrate these capabilities in Sastric Sanskrit, consider the
"bahuvrihi" construct (literally "man with a lot of rice") which is
used currently in linguistics to describe references outside of
compounds.
>If it were a relational database, and this were of any practical
>importance to either they or the customers they want to have, then it
>would make sense for them to use the word somewhere in the main page
>of marketing. _Reality_ is that most of the people targeted by their
>marketing for Access likely wouldn't know a "normalized form" if it
>bit them on the butt.
That is my point, that web page is purely marketing at a specific user
sector. It also doesn't mention indices, table and column validation,
etc., does that mean that Access doesn't have them?
>It goes without saying that cars have seats.
OK, bad example, not all cars have ABS, traction control, and other
features that are important to some sectors of the market, you can't
expect the first page to include everything.
Trevor Best <bouncer@localhost> wrote in message
<snip>
> >- does it allow duplicate rows in its tables ?
>
> If you let it.
>
That would be a "yes", then.
> >- does it allow nulls in its columns ?
>
> If you let it.
>
That would also be a "yes", then.
> Access (and Jet) gets a hard time in some circles, sure it's not in
> the same league as SQL Server, Oracle, Sybase, DB/2, etc but for what
> it is it's a good product.
Hmm !
> The trouble is that it's so easily
> available (pre-installed on your new PC?) and cheap and easy to use
> that any idiot can make a database in it, unfortunately many do.
>
That's for sure.
> If a complete numpty went out and bought SQL Server and produced a
> database that broke most relational rules in the book, repeating
> groups, no primary keys, no foreign keys, no unique indices, etc,
> would that be a reflection on the product or on the person designing
> the database? Ask anyone and they'l point straight at numpty, if he
> did the same thing with Access, they'd point at the product.
>
I doubt that. If someone bought a Mini and ran someone over with it,
and someone else bought a Ferrari and ran someone over with it, I
doubt that the choice of vehicle would make any difference to anyone's
evaluation of the situation. Similarly with "database" products.
Although to make the analogy a little better, the cars ought to be
fitted with homing devices that ensured that you ran someone over at
least once a day, given that they encourage such bad practices as
duplicates, nulls, etc. etc.
If it doesn't deal with relations, it's not relational. Full stop.
- Tony
<snip>
> By this definition then, Oracle is not an rdbms. <shrug>
Correct. It's a SQL database. Not the same thing, by a long shot.
- Tony
> Access doesn't have tables or columns. Jet has tables of sorts as does
> SqlServer.
Hmmm... I vaguely remember about the separation of Access from the MS
Jet engine from some time ago. The question then would be, could
anything useful be made of the MS Jet engine (I'd seriously doubt it)
?
- Tony
> Access will, or will not, allow duplicate rows in a table, depending on
> how the table is defined.
See that word "table" ? Not the same as "relation".
> Access will, or will not, allow nulls in its columns, depending on how
> the column is defined.
So, the answers are, that the Jet engine will permit duplicates and
nulls. Therefore, it doesn't manage relations; therefore it's not an
RDBMS. By definition.
- Tony
Can and must are two very different things. An RDBMS must prevent duplicates
and must represent all data as values in relations.
Jet is a file processor with an SQL parser tacked on the front of it. It
goes out of its way to expose the physical schema in the logical schema
mostly because it lacks anything resembling an optimizer. Jet not only
allows but encourages subversion.
If one understands the above issues (and others) and if one fully
comprehends the implications, one can rationally decide to use Jet for other
reasons and actually make something useful with it. However, almost nobody
who has ever chosen Jet understands the above issues or their implications.
The original question in this thread and most of the answers to it clearly
demonstrate that.
OK, I understand your statement now, thanks.
So would I be correct in saying an RDBMS is actually an application that
can be built up on either of these platforms (Oracle, Jet) or others? I
would think one's design approach would be paramount here, would it
not? I am constantly in misery here at work due to number of managers
and, indeed, supposed DB developers who create things using both Jet and
Oracle whose structures are more closely related to a spreadsheet rather
than anything relational.
Categorically no! An RDBMS is a system and not an application, and it is a
system built on the relational model in a non-subvertible manner.
> I
> would think one's design approach would be paramount here, would it
> not?
No. The design approach has nothing to do with which logical data model a
dbms exposes to users. That logical data model is either relational or it is
not relational.
Regardless, these issues are totally irrelevant to whether an end-user query
tool or a file processor is an rdbms. Neither are a dbms let alone an rdbms.
> I am constantly in misery here at work due to number of managers
> and, indeed, supposed DB developers who create things using both Jet and
> Oracle whose structures are more closely related to a spreadsheet rather
> than anything relational.
One can apply the lessons of the relational data model to other data models,
and an intelligent, informed data manager will always do so as much as
possible. However, user application of relational principles does not change
the underlying logical data model of a dbms.
[snip]
>Jet is a file processor with an SQL parser tacked on the front of it. It
>goes out of its way to expose the physical schema in the logical schema
>mostly because it lacks anything resembling an optimizer. Jet not only
>allows but encourages subversion.
Could you please give an example of this?
[snip]
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
> The original question in this thread and most of the answers to it clearly
> demonstrate that.
>
>
Any answers to a thread entitled "Is MS Access a relational database
system?" and cross-posted using a remailer to both comp.databases and
comp.databases.ms-access demonstrate merely that people cannot recognize a
troll even when the said troll is staring at them in the face.
"Bob Badour" <bba...@golden.net> wrote in message
news:UQ33b.14$mz1.3...@mantis.golden.net...
Whether the original post was a troll has no bearing on what the answers to
the post demonstrate. One may recognize a troll and still choose to answer.
"Saintor" <sain...@REMOVETHIShotmail.com> wrote in message
news:mC63b.6494$k5.5...@wagner.videotron.net...
After reading your posts, INHO I think you are insane.
Good. I think it is great that you can form an opinion and that you can
express your opinion. By all means, try to convince others to share your
opinion.
In the meantime, I consider myself honoured to count among the educated
considered insane by the ignorant. It places me in excellent company with
the likes of Semmelweis, Lister and even Gallileo and Socrates. Though, I
hope I have no risk of Socrates' fate. In short, Patrick, thank you! You
have no idea what a cherished compliment you have given me.
http://www.seanet.com/~alexs/ascorbate/198x/forman-r-med_hypotheses-1981-v7-
n8-p1009.htm
>> Would you call MS Access a relational database system?
>
>MS Access is an end-user query tool.
And what about forms, reports and VBA?
>Jet is not even close to a relational
>database management system. Jet is a rather primitive file processor.
<chuckle> Works for my clients.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
What about them? I expect them in an end-user query tool. They sure as hell
don't have any part to play in an rdbms.
> >Jet is not even close to a relational
> >database management system. Jet is a rather primitive file processor.
>
> <chuckle> Works for my clients.
I guess I don't find your clients' ignorance and stupidity as funny as you
do, but then I am not making any money off them.
>> >> Would you call MS Access a relational database system?
>> >
>> >MS Access is an end-user query tool.
>>
>> And what about forms, reports and VBA?
>
>What about them? I expect them in an end-user query tool. They sure as hell
>don't have any part to play in an rdbms.
Ah, so you object to Access including Jet then?
>> >Jet is not even close to a relational
>> >database management system. Jet is a rather primitive file processor.
>>
>> <chuckle> Works for my clients.
>
>I guess I don't find your clients' ignorance and stupidity as funny as you
>do, but then I am not making any money off them.
For them Access works and works well. They have 20-25 users in all day long entering
data, inquiring and reporting. Sure they should upsize the backend to SQL Server
but that hasn't been a priority yet.
I'm quite puzzled as to the negative comments you and others have posted.
All I have to say is in my .signature...
--
output = ("cbbrowne" "@" "ntlug.org")
http://www.ntlug.org/~cbbrowne/linuxdistributions.html
"They laughed at Columbus, they laughed at Fulton, they laughed at the
Wright brothers. But they also laughed at Bozo the Clown."
-- Carl Sagan
ROFL! I appreciate your humour. All I can say is: "Dr. Science, move over
and make room!" http://www.ducksbreath.com/
No, I have no objection to an end-user query tool including a primitive file
processor as a bundled freebie. Why would I?
> >> >Jet is not even close to a relational
> >> >database management system. Jet is a rather primitive file processor.
> >>
> >> <chuckle> Works for my clients.
> >
> >I guess I don't find your clients' ignorance and stupidity as funny as
you
> >do, but then I am not making any money off them.
>
> For them Access works and works well.
If they have a rational need for a primitive file processor, then I expect
it would work well for them. Why wouldn't it? If that is the case, though,
then I guess I just don't understand what you find so funny.
The question is: Do they really have a rational need for a primitive file
processor?
> I'm quite puzzled as to the negative comments you and others have posted.
I don't see what is negative about calling an end-user query tool an
end-user query tool. It might be a damned fine end-user query tool, but it
most certainly is not a dbms let alone an rdbms. Likewise for calling a file
processor a file processor.
Hmmmm, thanks Bob, but I'm confused. Are you saying then that Oracle is
not an RDBMS? That seems to go against what I have learned, but then
again, I have no formal training in DB development. IS there some
place, preferably on line, that you know of where I might read about the
distinction your making between all these terms? Terms which I have
used somewhat interchangably (and possibly incorrectly) over time.
Thanks in advance for any pointers.
In that Oracle allows duplicate rows, NULL etc., no it does not conform well
to the relational model; however, one can say the same for all SQL dbmses.
Oracle is a dbms. One could argue that one must first add hardware and an
OS, but nobody questions whether Oracle supports many of each. In that SQL
(and hence Oracle) were somewhat inspired by relational principles, one can
argue that Oracle qualifies more as an rdbms than other dbmses whose logical
data models in no way resemble the relational model.
> That seems to go against what I have learned, but then
> again, I have no formal training in DB development. IS there some
> place, preferably on line, that you know of where I might read about the
> distinction your making between all these terms?
Online? http://www.dbdebunk.com/
> > Ah, so you object to Access including Jet then?
>
> No, I have no objection to an end-user query tool including a primitive
file
> processor as a bundled freebie. Why would I?
>
The last two versions of office with ms-access have always included the
personal edition of sql server (the MSDE). The difference between the
personal edition of sql server and the MSDE is that the Enterprise Manager
is not included, but you can use ms-access in place of the EM to create,
manage and use tables on sql server anyway (access can be used as client to
either engine).
So, I think as mentioned, ms-access is not a database system, but only a
client product. However, that database engine included on the office cd
(MSDE) is generally viewed as a rdbms. There is perhaps some definitions
that would imply that sql-server is not a rdbms, but then so be it. However,
if the general view is that sql server is a rdbms, then the database engine
included on the office cd with ms-access would also thus be considered a
rdbms.
In addition to the 100% sql server compatible engine on the office cd, there
is also the file share engine called JET.
You have to go back more then the last two versions of office to find a
version of ms-access that did not include the 100% compatible MS sql server
engine on the cd. Right now we are testing office 2003, so we are now almost
into 3 versions of ms-access that have shipped with a ms sql compatible
server based data engine.
So, we have to be real clear on what data engine on the office cd we are
talking about, because there is two engines on that cd you can use with
ms-access (and one of them does NOT require you to use JET, but only a OLEdb
connection with NO local tables even being allowed!).
--
Albert D. Kallal (Microsoft Access MVP)
Edmonton, Alberta Canada
kal...@msn.com
http://www.attcanada.net/~kallal.msn
Why does the parsing of SQL strings by any method exclude Jet as a RDBMS?
Does it matter how the execution plan is derived?
> the DISTINCTROW
> clearly shows that it does not use tables,
I do not understand this conclusion. Jet "appears" to use tables, which is
all that is needed. The underlying technologies are irrelevant. But the use
of a file-server approach is a major limitation, I agree.
>pivots are reports and not
> queries,
Are they? Jet returns the results as a table. That table may or may not
source a report. Or do you mean that they are read-only?
>forms are not part of an RDBMS,
Quite so, and it is Access the interface-builder which has them, not Jet.
>and it does not conform to
> Standard SQL.
Yes, it is a small, rather mutated subset of SQL, but then is there any
fully-implemented SQL-Standard RDBMS out there? C J Date: An Introduction to
Database Systems 8th Edition, 2003 (but copyright 2004 - sic) says no.
>
> It is an application development tool built around an indexed file
> system with a front end that looks like (but does not work like) SQL.
That seems a fair statement, excluding the parentheses. It would be nice if
Access/Jet implemented SQL better, but the subset is probably reasonably in
keeping with the file-server basis of the db engine. It has served an area
of human enterprise well, and continues to do so. Access by itself is useful
as an interface tool to many other systems.
Clive
Of course, even if everybody here did agree with him, it wouldn't make on
iota of difference to their lives. They would still go on using the same
products, as long as the products enabled then to build the apps they
wanted.
Regards
Peter Russell
- Tony
I don't know enough about the specific features of MSDE and EM to conclude
whether MSDE is a dbms. It is certainly a significant component of a dbms,
in any case. The tactic of using MSDE during development certainly makes
sense.
> So, I think as mentioned, ms-access is not a database system, but only a
> client product. However, that database engine included on the office cd
> (MSDE) is generally viewed as a rdbms. There is perhaps some definitions
> that would imply that sql-server is not a rdbms, but then so be it.
Sql-server is without question an SQL dbms, which means it is about as
relational as other SQL dbmses and falls about as short as other SQL dbmses.
> However,
> if the general view is that sql server is a rdbms, then the database
engine
> included on the office cd with ms-access would also thus be considered a
> rdbms.
Again, that might depend on the specific features omitted by omitting EM,
but I do not have sufficient knowledge to conclude decisively.
My only real point here is that ms-access has shipped with a 100% compatible
sql engine for the last two versions. It means that ms-access does not
necessary imply that it will operate as a file share mode using JET. When
using access, you can thus create bound forms that use a OLEdb connnetion,
and not JET.
Many also use JET via a ODBC connection to their server of choice, but
ms-access now gives all 3 choices:
1) mdb File share via JET
2) mdb file with JET to server via ODBC connection
3) NO JET, but only a OLEdb native connection to sql server/MDSE (no jet,
and no local tables are allowed in this config). When you use ms-access in
this way, when you create a table, or graphically set relations, the ddl is
sent to sql server.
--
Albert D. Kallal (MVP)
John
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Not necessarily. A dbms is a complete system for database management. It is
entirely possible for MSDE to require EM as part of the system to make it a
complete dbms. I don't know for sure, but it is certainly possible.
>The MDSE is identical in functionally to sql serer (you can even use the
>Enterprise manger with it!). So, likely it is a sql dbms.
Just to clarify, MSDE *is* SQL Server with the following limitations:
* Limited to 5 query threads.[1]
* Cannot act as a replication publisher[2]
* 2CPUs
* 2GB Database size limit.
SQL Server personal edition has the same limitation except the 2GB
size limit. Standard edition has no crippling limits and up to 8CPUs
and can publish replicas. Enterprise edition supports more CPUs.
[1] More than 5 users can connect, just no more than 5 concurrent
queries executing, user 6's query will wait in a queue until one of
the original 5 has finished.
[2] MSDE can be a replication subscriber.
--
Ride Free (but you still have to pay for the petrol)
(replace sithlord with trevor for email)
>
>Does this mean that "MS Access SQL" (or, programs upsized to SQL) is
>considered a "Relational" database system"
Apparently SQL databases aren't relational.
This does remind me of the French GPA crash helmet that was illegal in
the UK because it had no chin strap. It did have a flap to fasten it
to a person's head and thus would not be ripped off in the event of a
crash. Yet the UK law was very specific in that a helmet must have a
chin "strap".
> y...@somehost.somedomain (Kay) wrote in message news:<GID2b.559$yJ3.1...@news.uswest.net>...
>
>>Would you call MS Access a relational database system?
>
>
> I haven't used Access for a while, but you could ask alternative
> questions :
> - does it allow duplicate rows in its tables ?
> - does it allow nulls in its columns ?
> If the answer to either is "yes", then it doesn't deal with relations,
> therefore can't be a relational database management system. It might
> still qualify as an SQL DBMS, though. Like I say, I haven't used
> Access since 2.0.
>
> - Tony
By this description Oracle isn't a DBMS either, because I can create a table
which does allow nulls in columns and allows duplicate rows....
You misunderstand something, Thomas. Oracle is not fully relational, but it
is most certainly a dbms.
I always thought it was....
Thomas
>>
>Well obviously I did misunderstand something.
>Why isn't Oracle not fully relational?
>
>I always thought it was....
Thomas, google the other parts of this thread, pleeeeeeease, it's gone
on long enough and the same questions are being asked again and again.
Why the insult? I have more education than you do and
I do not like to converse with people obsessed with anals.
when I asked a question about Access, and when an "ordinary"
people talk about, they do expect an database engine, either
Jet or otherwise. Acess alone does nothing without it.
>
>Any answers to a thread entitled "Is MS Access a relational database
>system?" and cross-posted using a remailer to both comp.databases and
>comp.databases.ms-access demonstrate merely that people cannot recognize a
>troll even when the said troll is staring at them in the face.
I take offense to the above post. I am not a troll
and I asked the question in earnest. This question/
debate is nothing new. I only brought up this question
because what happened a few days ago.
My Access-using client got a proposal from somebody
to offer to write the entire data management software,
claiming Access is no good because it is not relational.
In my interest of defending my client, I responded
that whether Access is relational or not is not the
issue. The real issue is whether Access does or doesn't
do the job for my client. Yet, the entire discussion centered
around whether Access is relational or not. Because
of his dogmatic attitude, he lost the sale.
Then it got me thinking about the theoretical aspect.
Access, with Jet Engine in the background, it has
most of relational aspects, yet, many Access opponents
pooh-pooh it while its proponents think it's a gift from God.
Are we in a religious war here? Do some people like it
because they are familiar with it, because it's
readily accessible, because it is a Microsoft product?
Do some people hate it because it is simple to use
(you know what I mean), because it is a Microsoft product?
As C.J. Date points out, there is no product that is truly relational.
Then the question is how many deficiencies Access
can have to be truly relational. More specifically,
how many deficiencies are allowed to be called relational?
I brought this question here because I thought it would lead
to some interesting discussion. I cross-posted to
comp.databases because this would be a relevant topic
there, as well. I figured I would find more proponents in
Access group and thumb-down group in databases group.
No, Mr. Winterbottom, I am not trolling. I want to hear
opinions from more knowledgeable people than I, from
which I could form my own opinion. Isn't that what
this group is for?
Why is null issue is important. Shouldn't null be allowed
anyway, provided that it is not a candidate key?
Did you read the entire thread?
I wasn't insulting you. It was weak a pre-emptive strike on future
responders.
See if this helps.
http://www.youmightbe.com/pages/anal-ret.html
Nulls generally indicate that there's something somewhat broken with
the data model.
Either the model is demanding data that you might not have, in which
case the model is broken, or the data itself is deficient, and again,
something is broken.
Access doesn't really seem to know about NULL values; it instead seems
to map them to the "zero" for the field. Which is further broken,
because that then conflates NULL with "zero." (Or at least, that's
what I saw the last time I used Access...)
In effect, nulls are a problem, relational or no.
Different groups of people have different policies; the "map it all to
0" seems to be the _most_ broken policy in that it allows data to get
invisibly corrupted.
--
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/internet.html
"I will not send lard through the mail" ^ 100 -- Bart Simpson
>Nulls generally indicate that there's something somewhat broken with
>the data model.
>
>Either the model is demanding data that you might not have, in which
>case the model is broken, or the data itself is deficient, and again,
>something is broken.
>
>Access doesn't really seem to know about NULL values; it instead seems
>to map them to the "zero" for the field. Which is further broken,
>because that then conflates NULL with "zero." (Or at least, that's
>what I saw the last time I used Access...)
Which version was that? The old DOS comms program? I've used Access
since version 2.0 and it has never confused null with zero or a zero
length string, it has always treated null as null.
>In effect, nulls are a problem, relational or no.
Not to those who know how to handle them.
>Different groups of people have different policies; the "map it all to
>0" seems to be the _most_ broken policy in that it allows data to get
>invisibly corrupted.
Nulls are generally used by most to signify an unknown value (as you
alluded to in your second paragraph) and since the column allows null
then your statement of "demanding data that you might not have" is
simply not true as it's clearly not demanding anything.
--
A)bort, R)etry, I)nfluence with large hammer.
I agree that an end-user query tool is pretty useless with nothing to query,
but that doesn't change an end-user query tool into something else. I really
don't find it surprising for this reason that Microsoft bundles a file
processor with it.
You were absolutely correct to respond as you did. One must first answer
whether the client requires an rdbms or an end-user query tool. Perhaps your
client requires both. It is absurd for you, your client and someone else to
argue over the relational fidelity of an end-user query tool. The concept of
relational fidelity applies to dbmses and not to end-user query tools.
> The real issue is whether Access does or doesn't
> do the job for my client. Yet, the entire discussion centered
> around whether Access is relational or not. Because
> of his dogmatic attitude, he lost the sale.
>
> Then it got me thinking about the theoretical aspect.
I don't know that any theory exists for end-user query tools apart from
normal theory of computing.
> Access, with Jet Engine in the background, it has
> most of relational aspects, yet, many Access opponents
> pooh-pooh it while its proponents think it's a gift from God.
The ignorant often substitute faith for learning.
> Are we in a religious war here? Do some people like it
> because they are familiar with it, because it's
> readily accessible, because it is a Microsoft product?
>
> Do some people hate it because it is simple to use
> (you know what I mean), because it is a Microsoft product?
What about the people who do not hate it, but simply recognize it for what
it is?
> As C.J. Date points out, there is no product that is truly relational.
> Then the question is how many deficiencies Access
> can have to be truly relational. More specifically,
> how many deficiencies are allowed to be called relational?
That's kind of like asking how many deficiencies a Geo Metro can have to be
a wide-body jet aircraft. It's a nonsensical question.
> I brought this question here because I thought it would lead
> to some interesting discussion.
Interest is subjective. As they say, there is no accounting for taste.
> I cross-posted to
> comp.databases because this would be a relevant topic
> there, as well. I figured I would find more proponents in
> Access group and thumb-down group in databases group.
How does the above differ from a troll?
> No, Mr. Winterbottom, I am not trolling. I want to hear
> opinions from more knowledgeable people than I, from
> which I could form my own opinion. Isn't that what
> this group is for?
Isn't that what a good troll is for?
You'd be worth arguing with if you were a little smarter. As it is you are
just ... BORING!
Go away and impress some nothings.
--
Lyle
I apologize for that rude response. And after thinking a bit I realize you
would not be worth arguing with unless you were a LOT smarter.
--
Lyle
While I hesitate to engage in armchair psychology, you seen to say you had
nothing of worth or value to add to the discussion, and your inadequacies
drove you to toss in a little ridicule of those who do. Does that about some
up your position?
>My Access-using client got a proposal from somebody
>to offer to write the entire data management software,
>claiming Access is no good because it is not relational.
>In my interest of defending my client, I responded
>that whether Access is relational or not is not the
>issue. The real issue is whether Access does or doesn't
>do the job for my client. Yet, the entire discussion centered
>around whether Access is relational or not. Because
>of his dogmatic attitude, he lost the sale.
Good. Glad to see a dogmatic and anal idiot lost the sale. As you state if Access
does the job then that's what's important. Which is exactly how my clients approach
the matter.
Except for a few members of one clients IT department who can't quite grasp that it's
more important to give the users some working software than it is analyze the
solution to the nth degree and come up with the perfect solution.
But the perfect solution has the following problems:
1) Only the senior managers were consulted for the details of how the system should
work
2) The environment chose is VB/VB.Net which can take 50% to 100% longer to write the
same solution
3) It ends up taking twice or three times as long by the time all the meetings and
such happen and costing twice or three times as much.
>Then it got me thinking about the theoretical aspect.
>Access, with Jet Engine in the background, it has
>most of relational aspects, yet, many Access opponents
>pooh-pooh it while its proponents think it's a gift from God.
>
>Are we in a religious war here?
Pretty much.
>As C.J. Date points out, there is no product that is truly relational.
>Then the question is how many deficiencies Access
>can have to be truly relational. More specifically,
>how many deficiencies are allowed to be called relational?
Apparently none according to some posters. But then no product out there is
relational either.
>I brought this question here because I thought it would lead
>to some interesting discussion. I cross-posted to
>comp.databases because this would be a relevant topic
>there, as well. I figured I would find more proponents in
>Access group and thumb-down group in databases group.
<chuckle>
>No, Mr. Winterbottom, I am not trolling. I want to hear
>opinions from more knowledgeable people than I, from
>which I could form my own opinion. Isn't that what
>this group is for?
Correct. But at first glance without this explanation your initial posting could be
construed as such.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
>Why is null issue is important. Shouldn't null be allowed
>anyway, provided that it is not a candidate key?
Sure. There are times, when a patient is bleeding in front of you in ER, when the
address simply isn't important. Next of kin however might be. <smile>
Which brings up the next thought on this one which will likely start another looong
thread.
Address lines. Usually you only need one. But sometimes you need two. So what do
you do when you only need one? Leave the second address line as null? Put N/A in
there?
You are the poster boy of those I was taking a shot at.
Point to something of value you posted in this thread.
I can't find it.
No address line should be null. The relation should hold precisely the
number of lines required, no more, no less.
Clive
"Tony Toews" <tto...@telusplanet.net> wrote in message
news:87v4lv4251bic16cm...@4ax.com...
> y...@somehost.somedomain (Kay) wrote:
>
> >Why is null issue is important. Shouldn't null be allowed
> >anyway, provided that it is not a candidate key?
>
> Sure.
> Address lines. Usually you only need one. But sometimes you need two.
Has it ever occured to you to put a known string with length zero in one of
them?
Of course you cannot find it. You lack the most basic requisite education to
recognize value in a discussion of data management issues, which is why you
had nothing of worth or value to add to the discussion in the first place.
It really does not matter to me whether you pursue a maladaptive, short-term
and immediate emotional gratification or if you find the courage to remedy
the educational shortfall that renders you inadequate in the first place
(assuming you have the necessary intelligence to succeed.)
Either way, I am happy to have helped you pursue your goals.
You mean like someone whose dogma and anal retentiveness insist an end-user
query tool is a dbms contrary to all evidence?
>> Good. Glad to see a dogmatic and anal idiot lost the sale.
>
>You mean like someone whose dogma and anal retentiveness insist an end-user
>query tool is a dbms contrary to all evidence?
What evidence? What definitions?
>It can be argued, and has been, that Address lines are a 1:M relationship to
>the address object, much like Invoice and Detail Lines. So, they should be
>another relation. (The multiple address lines so often used are in fact
>repeating fields - a no-no.)
>
>No address line should be null. The relation should hold precisely the
>number of lines required, no more, no less.
Which then requires another table, with joins and so forth.
No thanks, I'll keep things simple at the cost of not being truly relational.
>> Address lines. Usually you only need one. But sometimes you need two.
>So what do
>> you do when you only need one? Leave the second address line as null?
>Put N/A in
>> there?
>
>Has it ever occured to you to put a known string with length zero in one of
>them?
Why bother when Null does just as good a job?
You're right. I can't find any discussion of data management issues
in this thread at all.
As for maladaptive, short-term and immediate emotional gratification,
I'm sure the paragraph you wrote had you thinking how intellectual you
must appear to be having pieced it together.
Reads like you jerking off to me.
What makes you think CDB's statements had anything valid to do with the
relational model?
Because NULL does not do a good job at all. The typical albeit inconsistent
interpretation of NULL is "unknown". I know perfectly well that the second
address line of my address is an empty string. A known string with length
zero would do fine, but that is very different from NULL.
Consider a query requesting addresses whose second line is fewer than 5
characters long. The naive (and correct absent NULL) query will not include
NULL address lines but will include known strings whose length is zero.
Unless, of course, your SQL dbms makes the mistake of pretending the length
of an unknown character string is less than 5. NULL places a burden on the
user to ask for addresses whose second line is fewer than 5 characters long
or whose second line is unknown.
If someone can show me a system that follows all these valid (yet harped
on to the point of anal retentiveness) requisites that Bob and some of
the others are going on about without any effort from a developer, then
you've found these wonderful systems that the actors on Star Trek and
other goofy sci fi shows use. And I want to know what it is!
Of course, these same fellows will smirk with the usual patronizing
disdain demonstrated in this thread and write off those who don't agree
with their diagnosis of Access as "ignorant". Well, if it makes them
feel better, then while that's sad, they can fill their boots.
--
Tim - http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Want some?" - Ditto
Try that with a date or numeric data type.
In a table I have a planned, forecast and actual date for an event, the
actual date is unknown until the event actually occurs, what am I supposed
to do until that event occurs, lie about it?
Since when did the second line in an address become a date or numeric?
> In a table I have a planned, forecast and actual date for an event, the
> actual date is unknown until the event actually occurs, what am I supposed
> to do until that event occurs, lie about it?
You are supposed to use a better logical design than the one you have
planned. Pick one that more closely models reality.
>Centuries ago, Nostradamus foresaw when y...@somehost.somedomain (Kay) would
>write:
>> Why is null issue is important. Shouldn't null be allowed
>> anyway, provided that it is not a candidate key?
>Nulls generally indicate that there's something somewhat broken with
>the data model.
>
I don't think that's true at all. A robust database cannot be inflexible by
definition.
>Either the model is demanding data that you might not have, in which
>case the model is broken, or the data itself is deficient, and again,
>something is broken.
>
No - consider the law enforcement databases. Most records have null fields
otherwise there would be no fugitives would there. It doesn't mean there is
some thing "broken". It just means that there is incomplete data available. The
existance of the record itself proves the viability of the database.
>Access doesn't really seem to know about NULL values; it instead seems
>to map them to the "zero" for the field. Which is further broken,
>because that then conflates NULL with "zero." (Or at least, that's
>what I saw the last time I used Access...)
>
>In effect, nulls are a problem, relational or no.
>
That is not how Access treats null. Null is an entity which must be addressed
specificaly - that's all.
>Different groups of people have different policies; the "map it all to
>0" seems to be the _most_ broken policy in that it allows data to get
>invisibly corrupted.
Null cannot default to zero in Access unless coded to do so. Corruption By Null
is self inflicted. Exploitation Of Null is exhilarating.
>It can be argued, and has been, that Address lines are a 1:M relationship to
>the address object, much like Invoice and Detail Lines. So, they should be
>another relation. (The multiple address lines so often used are in fact
>repeating fields - a no-no.)
>
>No address line should be null. The relation should hold precisely the
>number of lines required, no more, no less.
>
I think there's a miscommunication on "relational". I see two tables. Table One
is related to Table Two by telephone number. Table Two has two address rows.
Table One doesn't have an address field nor do Tables Three thru Ten. Does that
make Table Two faulty?
Multiple address records are standard, btw. The USPostal Service even has code
out there somewhere that "translates" addresses.
All realtime CICS systems have multiple address records.
Isn't NULL a string of length zero?
Since no truly relational dbms can ever allow subversion, you're position is
facile. It amounts to: "If I start with a non-relational dbms or file
processor, I can find someone to demonstrate its flaws in about 2 seconds."
Since I actually understand what the relational model is and does, and since
I know that a dbms is much more than an "engine", I don't need to find
anyone. I can demonstrate flaws in non-relational dbmses and in file
processors all by myself in about 2 seconds.
> If someone can show me a system that follows all these valid (yet harped
> on to the point of anal retentiveness) requisites that Bob and some of
> the others are going on about without any effort from a developer, then
> you've found these wonderful systems that the actors on Star Trek and
> other goofy sci fi shows use. And I want to know what it is!
I have to say the access crowd is almost as mindless as the pick crowd. Not
quite as mindless but almost. I see such a herd mentality in the access
crowd they cannot even think up original ad hominem. I wouldn't be surprised
they all learned the term "anal retentive" in a book from microsoft press.
Just as none of you can tell the difference between a dbms and an end-user
query tool, none of you can tell the difference between an anal retentive
and a pedantic smart ass.
You seem to allege I have nitpicked inconsequential details--that, if only
Access had gotten one or two things right, it could be an rdbms. If you go
back and read this thread, you will see I have done no such thing. Access
has the desirable features of an end-user query tool and none of the minimal
features of a dbms--not any kind of dbms.
Some other individuals have piped up by repeating one or two specific flaws
in SQL that make SQL less than fully relational. Sadly, while these
individuals are actually trying to improve their knowledge, they still have
a long way to go. With respect to Access and even with respect to Jet, the
issue is not whether either has sufficient relational fidelity, the issue is
whether either is a dbms at all or whether they even aspire to be a dbms.
Lee Fesperman recently provided a good list of the minimal features of a
dbms. Access does not provide security and authentication; although, it
provides an interface to the security and authentication function provided
by a dbms. Access does not provide data integrity; although, it provides an
interface to some subset of common integrity constraints provided by dbmses.
Access does not provide concurrency control; although, it provides features
to automate responses to requests denied due to concurent resource
contention. Access does not provide optimization and performance. Access
does not provide physical management; although, it may provide an interface
to some physical management features of a dbms. Access does not provide high
availability.
If you think it is anal retentive to insist that a dog is not a horse and a
horse is not a dog, then I guess by your definition the label fits. I don't
understand why you think that would bother me, though.
> Of course, these same fellows will smirk with the usual patronizing
> disdain demonstrated in this thread and write off those who don't agree
> with their diagnosis of Access as "ignorant".
Anyone who claims to work in the field of data management and/or application
development who cannot tell the difference between a dbms and an end-user
query tool is ignorant, and it is not an innocent sort of ignorance. It's
similar to a self-proclaimed carpenter who cannot tell the difference
between a compressor and a nail gun or an accountant who cannot tell the
difference between a spread sheet and a balance sheet or a doctor who cannot
tell the difference between a sphincter and a sphygmomanometer.
Your knee jerk emotional reactions to my comments about a software product
are just further symptoms of your ignorance. Had you a minimal education in
your field, you would have sufficient emotional and intellectual security to
accept the validity of my statement or to reason a substantive argument
against my position. Instead, my comments about a software product hurt your
feelings. Think about that for a moment or two.
You have correctly identified condescension and disdain. Has it never
occured to you that you have earned condescension and disdain? Would you
disdain an incompetent doctor or an incompentent accountant or an
incompetent carpenter or an incompetent mechanic? I suppose the doctor might
seek the psychological solace of imagining a fantasy smirk too.
> Well, if it makes them
> feel better, then while that's sad, they can fill their boots.
My recognition of your ignorance and incompetence has no effect on my
emotions whatsoever. I agree, though, that the widespread ignorance and
incompetence in our field is sad.
> > Try that with a date or numeric data type.
>
> Since when did the second line in an address become a date or numeric?
Since the poster tried to apply your very limited example to other
situations. Your response is trollish, at best. See the following.
> > In a table I have a planned, forecast and actual date for an event, the
> > actual date is unknown until the event actually occurs
> You are supposed to use a better logical design than the one you have
> planned. Pick one that more closely models reality.
Pray, how does such a design not model reality? And how would you model
the requirements the previous poster has set forward? Is one to
interpret from your responses here that in your obviously many and
varied projects you have not used a single date type field?
>As far as I'm concerned, these Jet/Oracle bashers have simply shown that
>they don't do much development. Insisting that a system enforce
>relations, etc, without any development, is ludicrous. Show me *any*
>database engine and I'll find you someone who can mock it up to be
>non-relational. IN about 2 seconds.
>
Access does what it is supposed to do. It's a wonderful piece of software. GIGO
and Idiot At The Helm explain most of the grousing.
>
>If someone can show me a system that follows all these valid (yet harped
>on to the point of anal retentiveness) requisites that Bob and some of
>the others are going on about without any effort from a developer, then
>you've found these wonderful systems that the actors on Star Trek and
>other goofy sci fi shows use. And I want to know what it is!
Snap out of it! You're talking about USERS fer god's sake. Desktop donkeys on
<name yer poison> Windows platforms.
>Of course, these same fellows will smirk with the usual patronizing
>disdain demonstrated in this thread and write off those who don't agree
>with their diagnosis of Access as "ignorant". Well, if it makes them
>feel better, then while that's sad, they can fill their boots.
I don't know what the fight's about, yet. I may have more frequent online
access now so maybe I will get to know whose on about what.
No, NULL is a marker that a datum is unknown or missing. NULL represents a
presumed valid, unknown string of unknown length. The empty string
reprepresents a valid, known character string with length zero.
Consider the following identities where the '+' symbol denotes
concatenation:
"" + "A" = "A" = "A" + ""
NULL + "A" = NULL = "A" + NULL
Length("") = 0
Length("A") = 1
Length(NULL) = NULL
TRUE = ( "" = "" )
FALSE = ( "" <> "" )
UNK = ( "" = NULL )
UNK = ( "" < NULL )
UNK = ( "" > NULL )
TRUE = ( "" <= NULL )
( S <= NULL ) = ( S = "" ) ? TRUE : UNK
( NULL >= S ) = ( S = "" ) ? TRUE : UNK
UNK = ( S = NULL )
UNK = ( NULL = "" )
UNK = ( NULL = NULL )
UNK = ( NULL <> NULL )
where UNK represents unknown in 3 valued logic.
etc.
The products you use may screw up some or all of the above identities, which
is why an education is important. Knowing a product is no substitute for an
education.
>Anyone who claims to work in the field of data management and/or application
>development who cannot tell the difference between a dbms and an end-user
>query tool is ignorant, and it is not an innocent sort of ignorance. It's
>similar to a self-proclaimed carpenter who cannot tell the difference
>between a compressor and a nail gun or an accountant who cannot tell the
>difference between a spread sheet and a balance sheet or a doctor who cannot
>tell the difference between a sphincter and a sphygmomanometer.
You're a monkey and I think you're funny. I just don't know why it's so
important to you to make fun of people who use a certain tool to do their jobs.
It's a desktop application fer god's sake.
You have probably posted your CV here? Do you have a Google link or date range?
I'd like to read it. I am particularly interesed in your background in
mainframe databases as those are genuine Turing tests.
> Isn't NULL a string of length zero?
No.
Press Ctrl+G in Access and type:
?Null = ""
?""=""
?Null = Null
A zero length string is a known value, it is and is meant to be a string of
zero length, i.e. intentionally blank. A null is a value that doesn't exist,
in fact it isn't a value and usually represents unknown.
For example: tblBlood and tblPatient, both tables having a BloodType column,
if it's null then the blood is not yet tested for type. Now match up blood
to patients for a transfusion. You do not want nulls equalling nulls here as
you'll be putting unknown blood into a patient with unknown blood. I'm no
medical professor but I can tell that would be a bit dodgy. Access will not
match on the null columns so likely are your patients will live (other
factors permitting, they're not getting a transfusion for laughs). Likewise,
allowing a zero length string into this scenario would not make this
hospital very popular with patients and family.