Is MS Access a Relational Database?

views:

380

answers:

+4 Q:

Is MS Access a Relational Database?

The database which follows 12Rules of codd is a perfect relational database, I have read some where that No Database is Pure RDBMS...

SQL Server is RDBMS.. however MS Access is not RDBMS, I am confused.. why so as we can created relations. links. in Access as well.. then what are the main criteria that defined a Database DBMS or RDBMS ??

Its a theoretical questions..

+5 A:

I've never thought of the DBs that Access can manage as anything but relational databases.

John at CashCommons 2010-08-19 18:20:29

+16 A:

Is Access a relational DB? Yes.

Is Access a desktop relational DB? Yes.

Is Access a tinker-toy that should only be used on the desktop? Yes.

Has a guy like me walked into a 50 million dollar a year business and found the whole damned thing running on Access? Yes.

Is this what I looked like after trying to help them? Boo Yes.

JustBoo 2010-08-19 18:35:39

loooooooooooool

subt13 2010-08-19 18:36:18

+1 bahhhh hahahaha

dotjoe 2010-08-19 18:40:44

+1 I worked for financial institution that was riddled with horrible MS Access databases that were simply the root of all evil...*shiver*

Peter Kelly 2010-08-19 18:44:42

++ very well done

John at CashCommons 2010-08-19 18:48:26

The reason that financial institutions work with Access is that they get more done that way. You'll quickly find out why if you talk to their DBA's :)

Andomar 2010-08-19 19:01:38

Albert, please do not use answer-editing as a way to comment on or change the answer.

Gabe Moothart 2010-08-19 19:31:58

@Albert - Access wasn't always a client, it was a self-contained standalone DB, and I'd be more likely to guess that rather than "new to computers" he's an old hand like me. Access was a tinker-toy, ill-suited to anything beyond storing your recipes or music collection info (certainly not the music itself), and had a wonderful habit of corrupting its own tables. It's improved since then, but when someone says "an Access database" they usually mean the toy, not the front-end capacity it has. ... and +1, loved the answer.

Stephen P 2010-08-19 19:55:25

@StephenNo, Access was ALWAYS a client tool to connect to the database you choose such as JET or whatever. For the last ten years you can use a native oleDE connection to sql server, and you not using JET at all. However, even before this native sql server ability, to use access, asp.net, vb.net c#, VB6 you had to choose what database you plan to use with those tools. It is downright stupid and ignorant to call VB6, or vb.net, or access a database when you not storing any data and are free to choose what database you are going to work with when you use that tool, be it c# or Access.

Albert D. Kallal 2010-08-19 20:13:15

@GabeThen correct the text. Please edit the text to reflect that we taking about JET and not access then. Or are you incapable of understanding the difference between a RDBMS and Access? I have no problem if you willing to correct and edit that text, but the meaning HAS to be changed since it is wrong as posted.

Albert D. Kallal 2010-08-19 20:19:33

@Albert That is what downvoting is for! Incorrect answers are allowed on StackOverflow. You cannot just go around changing questions that you think are incorrect.

Gabe Moothart 2010-08-19 21:25:15

@GabeIt not question of me "thinking" something is incorrect. As posted, this is incorrect. I guess this really comes down to your inability to grasp the difference between RDBMS and Access. I don't understand people like you who happy to be deceitful and are willing to go along with such garbage when you been corrected. This post is simply not a benefit to anyone in the community. This really comes down to how much you care about stackoverflow and the community here. Why are you even bothering to post here on stackoverflow if you don't care about corrections and don't care to learn?

Albert D. Kallal 2010-08-19 22:17:15

@Albert I don't really care if this answer is correct, that's not the point. The vote up/down system is for deciding how good an answer is. If you think you have a better one, post it and let the users decide. The point is that you are abusing the 'edit' link to unilaterally change the content of an answer, that is not what it is for. Of course I care about the community here, and that is why I don't want one person to go around fundamentally changing the text of a highly-voted question he disagrees with.

Gabe Moothart 2010-08-19 22:52:23

@GabeSo you are most happy and willing to be the self appointed judge and jury here to decide what is an edit compared to changing content then? Let me see if I have this right.When I issue an correction you don't like, then you are the all seeing judge and jury that it not a correction, but is considered changing content. And when you like the change, then it only a correction that stays then? Your hypocrisy is well noted here.

Albert D. Kallal 2010-08-19 23:20:16

The FAQ seems to encourage edits as a way to collaborate like a wiki.

Jeff O 2010-08-20 01:25:36

After our firm reached 49 Mil, we converted all Access apps to HyperCard.

Jeff O 2010-08-20 01:30:05

@Albert, you are missing the point Gabe is, very civil, trying to make. Please refrain from posting something in anger, you will thank yourself for it later.

Lieven 2010-08-20 06:52:51

@Jeff O, edits *are* encouraged but it shouldn't change the *intent* of a post.

Lieven 2010-08-20 06:56:29

@Lieven - I agree. That's why I don't edit other entries unless its cosmetic.

Jeff O 2010-08-20 13:03:57

The statement "Is Access a relational DB - Yes" is factually incorrect. Access is not a database. Jet/ACE is a database. I downvoted the question, though, for the tinker-toy comment, as it adds nothing at all to the informational value of the question.

David-W-Fenton 2010-08-20 21:06:27

+1 A:

MS Access is relational.. though it is designed for ease of use for non-programmers (point and click) rather than hosting large enterprise data.

Many advanced functionalities taken for granted in complete databases (like sql server or mysql) are reduced or missing in Access.

Roopesh Shenoy 2010-08-19 18:39:03

+2 A:

Access may not perfectly follow Dr. Codd's rules, but it is practical to consider it a relational database. When access was invented, there was still some uncertainty about whether relational would be the the dominant model. I can recall a time when FileMaker supported what it called a "flat file" model, claiming that it was simpler to work with. Against this backdrop, Access embraced the relation database model and took part in the great paradigm shift to relational as the default way to store data.

You don't hear much talk lately about Network databases or other older database models, but there are interesting developments moving away from relational into new territory. This is important to remember: some databases aren't relational at all! Within this broader context there is a mainstream relational database community that has been very successful, and Access is definitely part of that community, warts and all.

Paul Keister 2010-08-19 19:50:48

+2 A:

Is access a RDBMS? No

Is access a front end that can be used with most RDBMS systems? Yes

Do people substitute the word access for jet? Yes

Access is no more a RDMS than vb.net or visual studio however as it came packaged with a RDMS (even if it was just a file based one) called jet people often think that access = jet when it does not.

Kevin Ross 2010-08-20 07:10:32

+1 A:

Microsoft Access is an application development tool, not a DBMS and certainly not a database. A database is a collection of data, not a piece of software.

Access could in principle be used to develop applications on top of a relational database but the Jet/ACE file sharing system that comes bundled with Access is not strictly relational at all because it is merely based (very loosely) on the SQL model of data. SQL is in fact just a poor imitation of the relational model and Jet/ACE is therefore an even poorer one.

dportas 2010-08-22 21:30:17

What's the basis for the assertion that Jet/ACE is only "loosely based on the SQL model"? That's nonsense. Jet/ACE is no better or worse than any SQL database in terms of being relational.

David-W-Fenton 2010-08-24 20:00:56

@David-W-Fenton: Jet/ACE has some distinctly non-SQL, non-relational features like DLOOKUP, DISTINCTROW, presentation formatting features in table definitions and most of all the ability to define "relationships" between tables (Could it be that Microsoft Access is actually to blame for spreading a misconception that relational databases have something to do with "relationships between tables"?). These are more than just proprietary language extensions - they show that it is using a quite different model of data to the one in standard SQL and is even further from the one envisaged by Codd.

dportas 2010-08-24 21:11:57

DLookup() is not Jet/ACE, but Access. It's available from within Access via the Access expression service, but from outside Access, using just Jet/ACE (via ODBC or OLEDB or even DAO), it's unavailable.

David-W-Fenton 2010-08-25 19:43:32

DISTINCTROW is unique to Jet/ACE so far as I know, but it's pretty useful. But that's just an example of a SQL dialect -- every database engine has its own SQL dialect and SQL keywords that are supported in that dialect and not in others. This does not make Jet/ACE "only loosely based on SQL," it just makes it not based on an exact implementation of any particular one of the SQL standards (remember that Jet was created before SQL 89 was even fully finalized, and while SQL 92 was still in draft).

David-W-Fenton 2010-08-25 19:45:24

What is called "relational integrity" in Access is just foreign-key enforcement. So far as I know, all the features that fall under the Access term RI are found in every other relational database I'm aware of. Saying that the terminology used in the user interface makes it somehow different from all other SQL implementations is ridiculous -- it's confusing the surface for the substance.

David-W-Fenton 2010-08-25 19:47:04

But Jet/ACE Relationships create implict joins between tables (whether you create a foreign key or not). That's a feature completely contrary to the relational model of data. Codd invented the relational model with the specific goal of abolishing any kind of navigational or linking structure in the database. I'm not aware of any SQL-based DBMS that has such a feature.

dportas 2010-08-25 19:59:33

David-W-Fenton: "Saying that the terminology used in the user interface makes it somehow different from all other SQL implementations is ridiculous" It would indeed be ridiculous, but I didn't say that, you did.

dportas 2010-08-25 20:09:45

"Jet/ACE Relationships create implict joins" -- this is an Access UI feature, one you may think is a problem or that violates the Word Of Codd. It is not part of Jet/ACE itself, though, and even within Access, it that behavior can be turned off in the Access options.

David-W-Fenton 2010-08-27 03:24:55

You are attempting to criticize Jet/ACE for things that have nothing to do with Jet/ACE, that are, in fact, aspects of Access, which is completely independent of Jet/ACE (or, put another way, Jet/ACE is completely independent of Access). Your criticisms really have no basis whatsoever, so far as I can see, as you're taking aspects of Access and pretending they are features of Jet/ACE, when they patently are not.

David-W-Fenton 2010-08-27 03:26:34

The Relationships are data structres stored in the ACCDB/MDB database file AFAIK. It seems to me far from "patently obvious" that data structures stored in a database could be considered not to be part of that datbase. The relationships are surely accessible to any application accessing the database and not just Access. Logically, if those relationships are part of the data structure which the database exposes to the world then they are de facto database features - whatever technical name you give to them.

dportas 2010-08-27 10:50:31

BTW No special criticism of Access is implied. You seem to be a bit defensive about this point but I don't think there's any need to be. From a practical point of view Jet/ACE is not relational but then SQL DBMSs are not relational either - that doesn't mean you can't do useful work with them.

dportas 2010-08-27 10:54:37

For "relationships" read "foreign-key constraints". Every relational database has them, Are you saying they aren't "part of the database"? If so, you're saying that every relational database that exists has features that "aren't part of the database" but you seem to be ragging on Jet/ACE for having that. A database without relationships is not a relational database, whatever terminology is used to refer to those relationships.

David-W-Fenton 2010-08-27 19:54:40

The statement that "Jet/ACE is not relational" shows that you are not dealing with any sane definitions of the term "relational", particularly when you admit (as you must) that no RDBMS's in existence are "relational" by the definition of the term you're using. While these definitions might be quite helpful in database *theory*, they don't contribute anything useful at all to a discussion involving actual databases.

David-W-Fenton 2010-08-27 19:56:38

As to "defensiveness," there are huge numbers of people out there prepared to criticize Access and Jet/ACE who have never used either, and have no comprehension whatsoever of what they are and how they work. Anyone who makes statements about them that are not true (especially sweeping statements like yours) is going to draw my response. This is not "defensiveness" so much as devotion to correcting the record in a sea of misinformation.

David-W-Fenton 2010-08-27 19:58:13

David-W-Fenton: "A database without relationships is not a relational database, whatever terminology is used to refer to those relationships" Relational databases are named after *relations* not relationships. Relations have nothing to do with foreign keys and the presence or absence of a foreign key has nothing to do with whether a database is relational or not. As I did say before, there seems to be a misconception (at least among Access users) that relational databases have something to do with relationships - but that isn't the case, as anyone familiar with the relational model is aware.

dportas 2010-08-27 20:46:35

Every database engine has some method of implementing the theoretical relations. Without that, they'd be worthless, whatever they might be called. And, of course, in Codd's theory, the term "relation" is synomous with "table" in normal people's terms (http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf). I didn't know we'd flipped into theoretical terminology, as opposed to the real world, where people use the terms in non-mathematical ways and manage to communicate quite well.

David-W-Fenton 2010-08-28 20:00:17

So we should agree that the term "relational database" has only ONE meaning (theoretical or otherwise), ie: a database based exclusively on *relations* and relational operators. I think we also agree that a relation is something quite different to a relationship and is so by any definition, theoretical or otherwise. Unfortunately the two quite different terms seem to get used interchangeably in the Access world, which can lead to a lot of confusion and that's why I was trying to be precise about it.

dportas 2010-08-28 23:51:05

To recap: the issue with relationships in Jet/ACE databases is that they are a predefined navigational structure, contrary to relational database principles, and a feature not found in SQL DBMSs generally. You claimed that those relationships are not part of the database at all but are "obviously" features of Access rather than Jet/ACE. I disagreed. I think it is "obvious" that data structures stored in a database and exposed to the outside world self-evidently ARE part of the database. I think the average user would surely agree! That was the basis of my original answer, which you downvoted.

dportas 2010-08-28 23:57:41

I think you're making a semantic argument, that foreign-key constraints should not be called "relationships". I don't find that very compelling, as the terminology is much clearer in regard to what is being modelled. That is, it's the foreign-key restraints that enforce the "relations" between the tables. I also think it's almost never helpful to mix Codd-level theoretical terminology into practical discussions of particular databases, since the possibilities for confusion are nearly infinite.

David-W-Fenton 2010-08-29 21:08:12

Er, foreign keys enforce relationships, not relations. A relation is a set of tuples whose nearest equivalent in SQL and Access would be a table, not a foreign key. It's not Codd's terminology. It's a precise term that has been in use for more than a century by mathematicians and later by data management professionals. Since there is no simple alternative word that means the same thing it is certainly practical and necessary to use it when discussing relational databases. If you aren't familiar with these concepts then I would recommend a good book like C.J.Date's "Intro to Database Systems"

dportas 2010-08-30 08:15:19

OK, it's obviously impossible to discuss this with you as you insist on using vocabulary form outside normal usage. End of discussion.

David-W-Fenton 2010-08-30 21:06:18

Relational database terms are quite normal in every educational and business environment I've been in. Since the question was specically about relational databases (ie databases based on relations) I think we have no sensible choice but to use those terms to answer the question.

dportas 2010-08-30 21:38:22

"Relation" (as you're using it) and "tuple" are terms from database theory, borrowed from the mathematical realm, and not database terms at all. Nobody on SO uses "relation" in the strict theoretical meaning, and nobody at all uses "tuple." Criticizing Access for doing exactly what every other database and everybody in technical forums dealing with databases seems churlish, and really introduced just to pick a fight. I'm sorry I took the bait -- I should have known better.

David-W-Fenton 2010-09-01 03:46:23

I am not "criticising Access" for doing what every other database does. In your confrontational style you seem determined to misrepresent me and pick arguments instead of answering the topic of the thread as I have done. You are flat wrong about SO. Relation (meaning the data structure with relational databases are concerned) is often used in the discussions on this forum and many others. Obviously it is a database term because it is the root of the word "relational"! Tell me what word you want me to use instead. "Table" clearly isn't sufficient because not all tables are relations.

dportas 2010-09-01 06:12:04

@David-W-Fenton: "DLookup() is not Jet/ACE, but Access. It's available from within Access via the Access expression service, but from outside Access, using just Jet/ACE (via ODBC or OLEDB or even DAO), it's unavailable" -- completely incorrect.

onedaywhen 2010-09-07 14:31:55

@dportas: A 'Relationship' in Access doesn't have to have referential integrity (RI) enforced. Not every Relationship is a FK but every FK will have a Relationship element to it. A Relationship without RI is pretty weak e.g. can be based on columns of different data types! You cannot do *anything* with a FK's Relationship element in Access SQL code; similarly, a Relationship has no effect on SQL code (DML, DDL, whatever). Therefore, as regards considerations relational, you can disregard 'Relationships'.

onedaywhen 2010-09-07 14:34:14

@dportas: it's worth noting that DAO (the data access component most Access coders will be familiar with) has distinct collections named 'Tables' and 'Relations' respectively, the latter being a contraction of 'Relationships'. I reckon this has caused much confusion in the Access community.

onedaywhen 2010-09-07 14:35:56

@dportas: ...but your comments about `DLOOKUP` and `DISTINCTROW` hit the mark (I've got a long email from Celko about the horrors of DISTINCTROW -- I think they consulted with him when the SQL Server team wanted to remove it).

onedaywhen 2010-09-07 14:36:45

@onedaywhen: you're right that DLookup() is available via more methods than I said. What those are, I can't tell, because I have no facilities for using Jet/ACE without Access without having to jump through hoops. But I just wrote a VBScript that uses DAO to open a recordset with a DLookup in it, and to my surpries, you're right -- it works. Whether that's DAO doing the heavy lifting or Jet/ACE, I don't know. Whether @dportas's citing of this as something "wrong" with Jet/ACE is convincing is debatable -- I don't use them in SQL, myself, only in VBA and in forms/reports.

David-W-Fenton 2010-09-07 18:00:52

It would be really bad if MS took away DISTINCTROW. It makes many views updatable that are not otherwise updatable, and that's closer to the theoretical ideal where all views should be updatable, even if it's badly named.

David-W-Fenton 2010-09-07 18:02:39

Does the criticism of DLookup extend to the domain aggregate functions? Now that I think about it, I don't think I use DLookup at all, just the domain aggregate functions (which are quick replacements for code that uses recordsets to return the same information), but not in SQL, but in VBA code and in forms and reports.

David-W-Fenton 2010-09-07 18:04:29

I just Googled to try to find a reference for what's supported in SQL by Jet/ACE from ODBC, for instance, but couldn't find any that are actually complete. Does anyone have any?

David-W-Fenton 2010-09-07 18:07:54

Is there a point to continuing this sub-thread? Fenton objected to my answer but then refuses to talk about relations in response to a question about the relational model!! The questioner specifically said it is a "theoretical" question. I assumed that meant he wanted an answer based on sound science. Unfortunately science is often treated with suspicion and even hostility in the IT field, especially so in the data manangement field. That's a pity because the science of data management contains so much that is relevant and useful to every day practice. Sadly some people won't even discuss it!

dportas 2010-09-07 20:28:02

@David-W-Fenton -- "what's supported in SQL by Jet/ACE from ODBC, for instance". It will be regular ANSI-89 Query Mode syntax. Microsoft have never published Jet/ACE help independent of the Access Help (at least not in the last decade) and the SQL language section of the Access Help has never been anything like as comprehensive as, say, the T-SQL BOL. As an exercise, try to find out anything about Jet/ACE CHECK constraints from official sources (it's practically non-existent). Plus Jet/ACE is far more buggy than TSQL. Conclusion: you need to experiment based on whatever clues you can get!

onedaywhen 2010-09-08 08:30:55

@onedaywhen: I have encountered lists of what is available in Jet/ACE SQL outside Access, but can't find them in my bookmarks. As to the inadequacies of Jet/ACE's DDL documentation, well, YAWN. You're not supposed to be using DDL. MS has designed it that way from the beginning, promoting DAO precisely because it's a much more capable way of programmatically manipulating your database than DDL. You may not like it, but it's the way it's always been, and, frankly, it's never been an issue for me, nor for any of the developers I know who use Access/Jet/ACE on a regular basis.

David-W-Fenton 2010-09-08 20:44:54

@dportas: you weren't having a theoretical discussion. You were having a SEMANTIC one.

David-W-Fenton 2010-09-08 20:45:42

Of course it was a discussion about semantics. The topic is about what it means to be relational! If you aren't willing to discuss that in a constructive manner then I don't know why you bothered to comment at all.

dportas 2010-09-08 21:17:26

@David-W-Fenton: "I have encountered lists of what is available in Jet/ACE SQL outside Access" -- Well, here (http://support.microsoft.com/kb/294698) is a list of VBA functions that can be called using Jet without Access. However, you mistook a Jet function for an Access one. So I figure you are looking for a list of Jet functions which, as I say, I've never seen (though many times I've looked) outside of the Access Help with has always been incomplete.

onedaywhen 2010-09-09 07:51:37

@David-W-Fenton: "You're not supposed to be using DDL" -- Let me get this straight: they design a SQL DDL syntax, expose it, document it (badly) and continue to publish it in the Access Help, on MSDN, etc. Yet I'm not supposed to use it? Thanks for pointing out the error of my ways :)

onedaywhen 2010-09-09 07:56:05

@onedaywhen: more than merely SQL 89 mode is supported. There are various functions, such as IIf() and the date functions that are recognized. But it's hard to tell which ones overlap with VBA and which ones do not.

David-W-Fenton 2010-09-09 21:45:40

@onedaywhen (to me): "you mistook a Jet function for an Access one." Er, what? The article you cite (http://support.microsoft.com/kb/294698) is about sandbox mode IN ACCESS, not about what is available with Jet when not using Access. Sandbox mode applies with or without Access, but the functions listed there are the ones available in Access, not with standalone Jet. So, that's not the right list at all.

David-W-Fenton 2010-09-09 21:49:58

No, they created DAO to provide better access to the object model the database engine uses than DDL provides. This is a feature, not a bug. I know you think this is heresy. MS doesn't think so. Nor do I.

David-W-Fenton 2010-09-09 21:51:24

@David-W-Fenton:"The article you cite (support.microsoft.com/kb/294698) is about sandbox mode IN ACCESS" -- indeed but ignore the title: that list of functions starting with `ABS` and ending with `Year` just so happens to be the same ones that can be run in Jet. Yes, some of them have changed behaviour (e.g. `IIF`) and some even take different arguments (e.g. `CDEC`); I haven't seen these documented, I had to discover the changed behaviour the hard way i.e. trial and error. But the list remains valid if you want to know "which ones overlap with VBA and which ones do not".

onedaywhen 2010-09-10 07:43:48

@David-W-Fenton: In addition, there are Jet functions that are not VBA functions e.g. `DLOOKUP`. Are you saying you've seen a list of these in a public Microsoft document in recent years? I would find that very hard to believe.

onedaywhen 2010-09-10 07:47:44

@David-W-Fenton: "they created DAO to provide better access to the object model the database engine uses than DDL provides" -- surely you are aware that there are some things that can only be achieved by using SQL DDL? CHECK constraints (as I mentioned), 'fast' foreign keys using the 'NO INDEX' keyword, reseeding or creating a larger step value for an `IDENTITY`... sorry, autonumber property. Then there are the things that DAO cannot do but SQL DDL can e.g. scale and precision for a `DECIMAL` column etc. The Access Team haven't always promoted DAO and SQL DDL remains to plug the gaps.

onedaywhen 2010-09-10 07:57:17

The limitations of DAO are artificial, introduced on purpose by Microsoft for political reasons. I have no doubt that eventually DAO will support everything that ADO did, since Classic ADO is obsolete, while DAO is not.

David-W-Fenton 2010-09-10 18:57:33

+2 A:

Is SQL Server or Access a 'database'? No, it is a database management system. A database is the collection of data a DBMS manages.

Is 'Access' a DBMS? Strictly speaking, its DBMS elements are known as Jet and ACE respectively (the official contractions) depending on the version. However, the term 'Access' tends to be used to refer to all its elements, even by Microsoft themselves. For example, if you want to find out about its CREATE TABLE statement you look in the 'Access Help'. Context is everything.

Is SQL relational? Strictly speaking, it is not relational e.g. it allows duplicate column names, duplicate rows, NULL values, reliance on column ordering, etc. [Note that Codd started it all but the field has since been developed by subsequent academics and practitioners: e.g. whereas Codd favoured two kinds of NULL, modern relational theorists argue for no NULLs at all.] However, the term 'relational' has long been used to refer to the organisation of data into tables of rows and columns (or relvars, tuples and attributes, if you prefer) and the concept of an optimizer; primarily in order to distinguish it from other models (notably ISAM). Hence, the need for the term Truly Relational DBMS (TRDBMS).

Is SQL Server a SQL product? Yes. Broadly speaking it is compliant with entry level ISO Standard SQL-92.

Is Access a SQL product? Not really. It has a SQL-like language but is fundamentally non-compliant as regards SQL-92 (and always will be). Furthermore, many of its non-compliant elements are decidedly non-relational (even when using the looser definition of relational).

onedaywhen 2010-09-07 14:02:55

Jet/ACE has its own SQL dialect, just like every database engine. It's compliant with some aspects of any particular SQL standard, just like every database engine, but not the entire standard. Just like every other database.

David-W-Fenton 2010-09-09 21:53:13

@David-W-Fenton: Be in no doubt: achieving SQL-92 compliance was very important to Microsoft, who gave a lot of cash to the SQL Server team to try to make it so. Ultimately they failed, mainly due to resistance from the Windows team who had build functionality on top of non-relational features in Jet. Access suffered many years of neglect as a result of this failure. I'm genuinely pleased to see Access enjoying a hiatus and I've even grown to like SharePoint, Access's saviour. But a SQL product? No. Multivalued fields was surely the final nail in the coffin in this respect.

onedaywhen 2010-09-10 08:11:49

@David-W-Fenton: Entry Level SQL-92 is the de facto minimum standard for SQL products. At no time has Access/Jet/ACE met this standard, and it never will. Take a look at the T-SQL syntax added to SQL Server for its 2005 and 2008 releases: they closely follow Standards. Then take a look at the same added to Access/Jet/ACE in the same era: very much not Standards. SQL Standards are important to Microsoft, have been for a long time, but no longer for Access. Where's the problem in that? There isn't one, unless you think Access is a SQL product.

onedaywhen 2010-09-10 08:16:38

Access/Jet/ACE predates SQL 92's final codification. That it doesn't conform to SQL 92 makes it no different than any other database engine that originated before SQL 92 existed as a fixed standard to aim for.

David-W-Fenton 2010-09-10 18:54:36

And, frankly, why should I give a rat's ass if Jet/ACE's SQL matches SQL 92 or not? It doesn't cause any issues for me at all, even though I work with SQL Server and MySQL in conjunction with Access on a regular basis. The issue you're raising is nothing but dogma and has no real practical effect on anyone actually working with Access.

David-W-Fenton 2010-09-10 18:56:07

ansaurus

tags:

views:

answers:

Is MS Access a Relational Database?

related questions