Since I usually give complicated answers to questions, I can't help but be amused.
First of all, I would like to thank the people posting in this thread as I am reading you all with great interest. I am reading a little more than I can absorb just now, but that's ok :) So. I, a newbie, have a couple of databases currently set up in mysql. From what I gather: Reasons to switch to Access truncation issue in mysql some issues with null values and numerics in mysql easier interface in Access Reasons not to switch to Access Possible security issues Performance issues? mysql may scale better Microsoft. I am sure there is a lot more that could be said, but are all of the above statements true? (OK, no need to flame me on the last reason; yeah, we all either agree with it or we dont, true) Dana On Sat, 14 Jun 2003 22:48:38 +0200, Jochem van Dieten <[EMAIL PROTECTED]> wrote: > Doug White wrote: > >> Please detail the inaccuracies. The Crashme authors want to know. > > It reports MySQL has a SQL 92 VARCHAR type. Since VARCHAR fields are not > allowed to loose trailing spaces, this is not accurate. > > It reports PostgreSQL does not have circular foreign keys or an ANSI SQL > identifier quote. > > It reports for many databases that they support subqueries, SUM, EXISTS > and GROUP BY. I know that at least Access and PostgreSQL fail the > following query: > SELECT projectnumber, > SUM(workhours) > FROM work > GROUP BY > projectnumber > HAVING EXISTS ( > SELECT projectname > FROM projects > WHERE projects.projectnumber = work.projectnumber > AND > SUM(work.workhours) > projects.budget / 200 > ) > I expect some more databases to fail this one, but according to the table > presented by that crash-me tool it should work. > (I didn't invent this query, it is from the NIST SQL Compliance Test.) > > And if we take the text on top "Some tests may fail because the database > in question does not follow ANSI SQL 92 or ODBC 3.0 but in this case we > regard this as a failure in the database." literally, many of the results > are not logical. > Why does the test show that "Calculate 1--1" is supported by databases, > while it is not even a calculation because "--" is the start of a line of > comment in SQL 92? > How can "Function OR as '||'" be a function if SQL 92 says it is the > concatenation operator? > How can " be allowed as a string marker when the SQL spec says it is an > identifier quote? > How can ' be allowed as identifier quote when SQL 92 says it is a string > delimiter? > > > And as for the completeness, I find the choice of listed functionality > rather curious. Abundant data on ODBC, yet nothing on JDBC, which is what > CF MX uses. > And nothing on OLAP functionality, WITH [RECURSIVE], object facilities, > the information schema, procedural languages and many other high end > features. > > All of this is quite understandable since MySQL AB uses crash-me for > regression testing of their own database, and there is little point in > testing things you don't support anyway. But that does mean it gives a > somewhat different result then if you would use the tools any of the > other databases. > > Just for a comparison, take a look at the following feature comparison > table and notice how suddenly the product of the company that created > that comparison shines (and check out their SQL validator): > http://developer.mimer.com/validator/comparison/comparison%20chart.tml > > Jochem > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
