Microsoft Access As A Client For Free Databases? 353
"Can this be done effectively? Is there any good documentation on connecting Access to Non-Microsoft DB servers in general, and MySQL in particular? No 'ODBC RTFM' flames, please; I'm looking for something a little deeper here."
I'm not very familiar with ODBC beyond it's basic use, so I really can't answer this question, but might this be possible if the MySQL server were somehow treated as an ODBC source? It would be tremendous coup if somehow the power of the Access front end could be used with MySQL (or PostgreSQL, or mSQL or any other open sourced RDBMS)? MySQL does have some ODBC functionality and as well as other ODBC related links on their site.
For those of you who want to immediately play around and see if this is possible, you can find the MySQL ODBC driver, here and a PostgreSQL ODBC driver here.
(My apologies. The story went live right as I was still editing it to include links in the last two paragraphs...)
odbc. (Score:1)
Re:That's a rather idiotic idea (Score:1)
Oracle put in the ban because people were publishing benchmarks showing dismal Oracle performance. Maybe that's realworld, maybe it isn't, but without an Oracle engineer looking over their shoulder, how would they know?
It's also why MS-SQL (which is sorta 'self-tuning') is a much better decision for smaller applications because you don't need a PhD DBA to muck with the thing.
Not to mention the standard benchmarketing is TPC, which Microsoft and IBM kick ass with by using 100s of 'small' x86 Xeon servers in a cluster -- something which doesn't affect any realworld applicaiton in any way (and if it does, you can collect the $1Million from Ellison).
ODBC with MySQL (Score:1)
I've actually ran into this problem a few times, and the deciding factor in my judgement was the scope of the app: if it needs to be web-accessible, your PHP/Perl and MySQL solution is probably better. But if its just an inter-office/use-on-the-LAN app, Access is probably a better choice.
For all of the greatness of PHP, Perl, and Access, there is only SO much a webpage can do. An app with an Access front end can have the same feel as any other VB based application, including combo-boxes and complex grids--thing impossible to do on a webpage. Data manipulation (in a GUI perspective) is far better in a VB based app than a web-page.
This would be the first step I took...
Re:If you're the DBA... (Score:1)
Re:That's a rather idiotic idea (Score:1)
Microsoft (and IBM) are benchmarketing by using totally unrealistic configurations for TPC-C - namely a cluster of 100s of 'cheap' Xeon servers instead of the more usual configuration of one big box.
You'll notice that Windows Datacenter and the Unisys 32 CPU jobbie don't show up anywhere. But this is the configuraiton that MS will mostly likely recommend if you had a real MS-SQL scalablity problem.
Which is not to say that MS-SQL is not an excellent product for midsized applications, just to counter the FUD.
Re:That's a rather idiotic idea (Score:1)
#2, Sybase is only free for development or non-commercial uses. The company I am working with right now checked into the Linux Sybase licensing for their commercial needs and it would have been around $15,000.
#3, SQL Server was indeed based off Sybase, but that was a LOOOOONG time ago and has since greatly diverged from Sybase. On the PC platform, I would suggest that SQL Server is far superior to Sybase.
ODBC Linked Tables (Score:2)
Re:That's a rather idiotic idea (Score:2)
Re:That's a rather idiotic idea (Score:2)
You're assuming I'm the usual slashdot fuckwit who screams Open Source the World at the top of his lungs. My selection criteria are much more rational. Oracle is faster, more robust, and runs on more platforms (most of which are vastly more scalable and reliable) than Microsoft's database. All other things being equal - and they pretty much are if it's between Oracle and the Microsoft database - I'll definitely take the better product.
Using Access with MySQL - I've done it! (Score:2)
Here's a section of the MySQL manual you should read beforehand:
http://mysql.com/documentation/mysql/bychapter/
You especially need to read the section about getting myODBC to work with Access. There are several glitches you'll need to work around.
That being said, I'd take a PHP or Perl frontend over and Access frontend, hands down...
Re:If you're the DBA... (Score:2)
I agree, 100%. (And I am not a DBA; just a sysadmin that has been bitten by stupid management decisions in the past.)
What people often fail to understand is that a production database can (and often does) have different requirements than a business database, especially if the term "production" means that it drives a web-based application. If the data model is designed correctly, it is possible to have two entirely seperate databases, with secure data transfers between them at appropriate times (the word "appropriate" is defined on a case by case basis, but it is almost never in real time).
In the company I work for, we have two, entirely seperate databases. Data is transfered and loaded between the two on a nightly basis (NOT via ODBC; ODBC is very slow, very insecure, and experience has shown that it is buggy at times. The data is dumped, ssh'ed back and forth, and loaded via custom scripts. Perl is your friend ;-) )
The production database uses replication to two seperate backup databases, and the business database is similiarly protected. Our replication scheme allows us to recover easily from data loss (which has never happened). The dba and our boss (who is a hacker first, and a manager second; a rareity these days) own the data.
This scheme allows the front end to be customized based on need. The business people are happy with their "point and click" interface, and the dba and engineering team are free to manipulate the data according to production application needs.
A solid data model can be implemented; all it takes is a great deal of foresight and solid software/database engineering practice.
Re:I'd think twice... (Score:2)
How long is a light year then? I thought it was shorter than a year, like light beer is less filling than regular beer.
I do not find in orthodox Christianity one redeeming feature.
MySQL backends for Access work fine (Score:2)
There are also 3rd-party scripts to dump a database and definition from Access into SQL for migration into MySQL.
We did run into issues with how Access treats some data types (I recall time/date as one) vs. MySQL.
So using Access as a client for MySQL works and is certainly better than using Access alone.
Longer-term, your employer may be more receptive to replacing Access if you can demonstrate the benefits of cross-platform portability, ease of creating a web interface, or other benefits meaningful to them.
Re:Don't weasel around the boss (Score:2)
I wrote the statement because the original poster obviously has a lot of feelings about implementing Microsoft solutions.
MS Solutions might be exactly what is needed, I am not arguing that. But what good does it do anyone for that guy to implement MS solutions, even though he hates it?
You're so fucking arrogant that you didn't even understand what *my* point was.
This post should probably be marked -1 flamebait, with a subtitle of (justified).
Re:Don't weasel around the boss (Score:2)
Fuck the company. They can do what they want. I was giving advice to someone who clearly doesn't enjoy implementing MS solutions. He's not doing himself any favors by staying there and slugging it out.
Life is too damn short to implement MS Solutions if your heart is with the Penguin.
Re:extending SQL (Score:2)
Hell, even MySQL doesn't support ANSI SQL. They support all the impotant stuff (UPDATE, SELECT, DELETE, CREATE), but not triggers, views, or SQL transactions. And they definitely do NOT support roll backs.
I love MySQL. It's elegant. Its fast. It's Free Software. But I'm going to have to agree with other posters...don't fool yourself thinking that MySQL is going to handle Access well.
ObJectBridge [sourceforge.net] (GPL'd Java ODMG) needs volunteers.
What about the front end? (Somewhat offtopic) (Score:2)
I'm running both Mac OS 9.1 and Red Hat 6.2 servers, with Mac OS 9.1 clients throughout. I'd actually consider making them all Yellow Dog Linux clients: FileMaker is pretty much the one essential application I can't give up, and I haven't seen any front ends nearly as flexible or easy to develop for. Thanks,
--Tom
Re:If you have to use Access... (Score:2)
Team FXML's product is excellent for what it does, and has perhaps the best support I have seen for any product, bar none, but it's not as fast or efficient for moving around large amounts of data as ODBC when communicating from a Windows client to a Linux server.
If you need to do updates to a SQL Server database from mySQL or anything else running on Linux, though, it's a godsend - my company has now pushed literally thousands of orders through it without any problems.
D
----
Re:If you're the DBA... (Score:2)
As a DBA, you shouldn't provide one that uses the database. I'm serious -- a production database has no business running SQL that hasn't been vetted by the DBA and run in a test database. The wrong kind of query can bring production to a halt for a manager's whim, and get you in the hot seat to boot.
That said, it's probably better to provide Microsoft Query and Excel rather than Access for "adh hoc query", if your needs are sufficiently simple. Unless you know how to enter "passthrough" queries, Access insists on reading entire tables and doing the filter/join itself. There is no better formula for poor performance.
If data need is not simple enough for MS Query, you need to design a data mart and produce preloaded spreadsheets, 'cause the boss won't understand how to get the data to come out. Give the boss a spreadsheet he understands and he'll be 10 times happier than with a point-and-click he doesn't.
Yes, I am a DBA...
Christ, get over it (Score:2)
Not that I don't like MySQL, it is a nice, simple and fast little database that has it's uses, but for any real world applications where cost is not an issue SQL server will be the simpler solution, especially when trying to integrate with an Access front end. Not to mention the fact that there are a hell of a lot more Access developers out there that know SQL server than there are that know MySQL.
Get over it, use SQL server, or find another job.
-josh
Re:That's a rather idiotic idea (Score:2)
"
Adaptive Server Enterprise for Linux version 11.0.3.3 download
Adaptive Server Enterprise for Linux version 11.0.3.3 continues to be offered as a free, unsupported release for development as well as deployment. Adaptive Server Enterprise for Linux version 11.0.3.3 is available from the Sybase Adaptive Server Enterprise for Linux version 11.0.3.3 download web page.
"
Sure, it's not very recent (latest version is 12.0, but there's a 12.5 beta available for testing), but as I said, it's free as in beer.
About ODBC support, sorry but I have no idea.
Re:That's a rather idiotic idea (Score:2)
I've heard that MS-SQLserver is a rip-off of Sybase, but I can't of course confirm this. They are so similar though, that you can use Sybase's client libraries (which are somewhat a brain-fart IMO, but they work somehow) to access MS-SQLserver's data...
Sybase is somewhat a big monolith if compared to the baredness and nimbleness of MySQL. But it will do the job nicely, I'm sure..
Re:PostgreSQL Outer joins (Score:2)
Pros and Cons of MySQL vs. SQL Server backend (Score:2)
x Backend may be faster if database is designed and configured properly
x Online support is better IMHO
Pros of SQLServer:
x Compatible security model with Access
x Can use stored procedures, transactions
x Uses the Jet Engine instead of ODBC
Cons of MyODBC:
x Some data types aren't supported by the MyODBC drivers
x Clients might have to get the latest Microsoft Data Access Components
Re:Not really (Score:2)
In the computer field, people don't seem to question statements like yours.
I know that some tuning is required for all products, like picking the gear to drive in, but a product that performs so badly in default that it gets beaten by another product in default configuration look really bad.
And as for the NT thing... For development work, compiling any fairly serious application in VC++ v6, NT is quite unstable. Not only does NT not completely protect memory (a malicious app can clober certain things, so can a buggy app that accesses those directly), but it also doesn't limit ram or CPU usage to provide a certain minimum level of functionality. It doesn't matter if NT technically hasn't crashed, if I hit ctrl-alt-delete and it takes ten minutes to swap until it pulls up the task manager, it's as good as dead.
I use NT4SP6a and W2kProSP1 on a daily basis at work and neither of them is 'enterprise ready' IMHO.
You can tweak and tune both so they they perform better, but no matter how well you tweak, they've still got many fundamental flaws.
I admit I've never used MS-SQL, but based on all other MS products, I wouldn't trust it with a big job (for your corporate website, sure, for your web-based commerce site, hell no.)
Sybase Adaptive Server Anywhere/Enterprise (Score:2)
If you are careful, you can keep your apps compatible with MS-SQL Server.
Why would you do this? Well Adaptive Server Anywhere is way cheaper than MS-SQL -- $1000 for ten users for a database with transaction logging, ANSI 92 intermediate compatibility, Transact-SQL compatiblity, replication, ultralight deployement etc.etc. It also comes with a web application server that's OK (I prefer Zope) and a very convenient case tool.
Re:Why Access? (Score:2)
"Relational" in FileMaker parlance means that it implements "relationships". This is not what "relational" means. Relational means that it implements at set of operations that are closed on the set of "relations" -- where relations are relations in the algebraic sense of a set of tuples [e.g. (a,b,c)].
This closure property is important, since it allows very, very powerful queries to be written succicntly and non-procedurally.
"Relational" in the FM sense is exactly the model that the relational model was meant to supplant.
I had a chance to talk to some Claris folks at a MacWorld a few years back when Claris still existed. Their position was that since buyers didn't understand what a relational database was, they were pretty much free to call their system "relational".
Re:That's a rather idiotic idea (Score:2)
MOD PARENT UP. (Score:2)
Re:not a "'ODBC RTFM' flame"... (Score:2)
One the MS-SQL ODBC driver is cursor based. When you do a select * from sometable or open up a form based on a table sql server does not return the whole keyset it returns a cursor with a few hundred records and waits for further insturctions. Chances are that the mysql or oracle ODBC driver does not use cursors and attempts to return the whole recordset. Check your options and see if you can turn on a cursor based option.
Secondly yes access sometimes decides it wants to do the query itself instead of sending it to the server. Either turn you query into a passthrough or create a view.
ODBC driver available for PostgreSQL (Score:2)
Re:Use Linux anyway (Score:2)
Non-Linux Solution: almost $30,000 equipment and software.
Linux-Solution: maybe $8,000 worth of hardware.
We are persuing the Linux solution and it is working so far (we're still in early rollout stages).
An earlier project had a $14,000 to $2,000 comparision and the implemented Linux solution is working amazingly well.
The only consession I had to make to my boss was to train my support staff and other sysadmin in Linux. Needless to say the other sysadmin is picking it up really fast due to his background in Unix and the rest of the support staff training is going really well.
I am tired of the old "How are we going to support this line?" So I'm coming up with my own answer.
The kicker is my corporation doesn't officially support using Linux for anything. But my boss is giving me support and is tickled at the cost savings Linux affords.
Re:Use Linux anyway (Score:2)
So no, it wasn't a bad decision.
Re:That's a rather idiotic idea (Score:2)
Coded wrong depends on what you want to do for backup. Some sites have the ability to shutdown and do cold backup / or exports for backups.
The Oracle backup and recovery handbook (from Oracle Press) is an excellent reference in this area.
Re:Pros and Cons of MySQL vs. SQL Server backend (Score:2)
MySQL is designed as a light-duty database engine.
Yeah it's faster than MS SQL Server when both are running on a 386 (not that MS will even run on a 386), but MySQL does not scale up to enterprise applications. Run both on a fast quad, dual or even single-chip server, with a large database being pounded by users, and MySQL will hit a brick wall. I saw this happen when an online forum [corvetteforum.com] with 14000 users (at the time) converted from UBB (using flatfiles) to another BBS system running a MySQL backend on a dedicated FreeBSD server. MySQL couldn't handle the load and just gave up. It's back on UBB now but there may be a Sybase back-end in the future. MS-SQL would handle it just fine also, if it were a Windows box. The point is that for that forum's particular application, even html flatfiles are faster than MySQL.
But then MS SQL would be overkill for a small application such as the one referred to in the original submission. A simple ODBC driver to MySQL would probably work, and it should work fine with a few dozen people using it. By comparison, the older versions of Jet (native Access) have been known to die with more than, oh, five people using it.
Re:Access can connect to/front-end for a MySQL DB (Score:2)
After defining an ODBC source to a particular database, choose "File:Get External Data:Link Tables" from your menu (or "Link Tables" from right-clicking), choose "ODBC" as your file type, and select your ODBC source. You will then get a multi-select list of all tables within the source's database. For ease of runtime usage, don't forget to select "Save Password".
Once you link the tables, the are completely accessible as any other tables except that they are read-only definitions. Other than that, if you use VB for manipulation, they are virtually identical in usage from local Access tables.
True, many posts are written of the limitations, but after two years of integration between Access and MySQL (through a port-forwarded SSL link even) I've not run into anything that made MySQL more difficult to use than Access or SQL Server 6.5/7.0.
Good luck.
Re:My Experience with Access and MySQL (Score:2)
This also holds true for every other RDBMS out there. Name one database that implements the complete ANSI SQL92 specification, without adding extensions to that specification. Nevermind SQL3.
(And no wonder. Have you ever tried to get your hands on the actual standards?)
This is not a defense of Microsoft or Access, by the way. Let's just not resort to the FUD tactics we malign in others.
---
That said, my love for free software notwithstanding, I must say that there are things you can easily do with a GUI interface that are difficult to achieve within the page-based metaphor of current web form design. The problem is that you have to pick a GUI, and that tends to constrain you to a particular environment. Web based form designs, on the other hand, can be deployed almost universally.
I find this dilemma very frustrating. Hopefully HTML (or derivitives) will someday offer a richer language for describing form-based interface layout and behaviour.
Hell With 'Em All (Score:2)
Re:That's a rather idiotic idea (Score:2)
We have a small database (26 thousand records), requires very fast reads, little is ever added or changed. It provides the journal listings from this page [ukc.ac.uk] (see the alphabetic listing). It does not require transactions. It is currently an Access database on a NT/IIS4 server.
The staff who edit it want to use Access. In my opinion, Access is a good DB client. It allows "average" users, who are advanced in the wonders of office apps, to edit and maintain the database, and use the find/replace and cut/paste commands they are used to. I can not see any obvious alternative for a client that works under windows and offers the same functionality.
You will note that the listings on the above page are created by an asp script. The whole web server is on NT. I'm not Microsoft bashing, though this has created a lot of problems. The asp stuff itself just dies (the mtx process goes mad and needs killing). We've spent days looking in to this with no luck.
We wanted to convert the DB to mySQL (easy, done in a couple of hours), use myODBC and let the staff use Access which uses the myODBC driver. We also re-wrote the asp scripts to php (being stupidly simple in what they do, this took a couple of hours). We would then be free to move our webpages to a nice Solaris box (which is still sitting there doing nothing), apache, php, mySQL, etc.
Not for love or money could we get the myODBC stuff to work with Access. We could connect to the database using a free (and very simple) client that is on the mySQL website, so the myODBC connection was working, though not with Access. The mySQL site does give some hints on using Access, but these did not help us.
I'm sure there must be many people in the same situation, i.e. they have a DB used just for some webpages though the staff (not techies, though they do know how to get the most out of office apps) who maintain that information want to use Access (for good reason, it is quite good for maintaining data), but the web server is on a UNIX platform.
We have had to put the project on hold while we work out a solution that does not involve any functionality loss for the staff who use Access.
Alternative open source DBs: SAP DB and InterBase (Score:2)
Take a look at InterBase [inprise.com] from Borland/Inprise as well. I quote from the product overview [inprise.com] :
Versioning Architecture for ultimate concurrency readers never block writers.
Active database, including the most full featured trigger and stored procedure implementation.
Event Alerters - React to database changes without polling. Exceptional ANSI SQL-92 compliance and full UNICODE support.
Rich data types - Blobs, multi-dimension-al arrays.
InterClient - all-Java JDBC driver for low maintenance.
Designed for business critical distributed database environments, InterBase provides power and flexibility for Internet, mobile, and embedded database applications.
Scalable from Windows 95/98, Linux, HP/UX, Solaris, and other UNIX systems.
INTERBASE SPECIFCATIONS
Integrity
- Declarative Primary Key
- Declarative Foreign Key
- Cascade Declarative Referential Integrity
- Domain and column-level Check constraints
- Trigger procedures with the following features:
- Unlimited triggers per record change
- Invoked before or after record insertion, deletion, or
update
- Multiple triggers per action, optionally ordered.
- Forward-chaining (cascading triggers)
Concurrency Control- Optimistic locking
- Data isolation levels: read consistency, read committed, and
cursor stability
- Shared, and protected lock types for explicit table-level locking
Availability- Online backups
- Immediate recovery after failure
Distributed DatabaseRe:If you're the DBA... (Score:2)
As the major shareholder of your company, I would immediately kick you out of the management if you make such commends officially with your name.
You obviously haven't used MySQL, nor are you aware of its capabilities. The original article is not specific about what they intend to do with the DB, and believe me, there are cases where MySQL is a very good choice. It won't solve all you problems, but if its strengths fits the task, then use it.
There's no need to play the big boss here, making these uninformed generalizations.
I worked on this once... (Score:2)
- Acess always requests at least three rows in a table. So if you're looking at row 1500, it requests 1499, 1500 and 1501. Maybe that's to allow fast load of the 'next' record? If so, it isn't used, because when you go from 1500 -> 1501, Access loads 1500, 1501, and 1502. So basically it just adds useless traffic to your database.
- Access seems to get into random moods where it sends tons of selects to the database. This usually happens when it's been idle for a few minutes. It can generate enough traffic to swamp MySQL.
- Access has a 'search' feature which data entry people like. If you want to find an employee with first name T-something, you type a 'T' in the first name box on the form, and tell Access to search. Now you might expect that Access would issue a query: SELECT * FROM EMPLOYEE WHERE FIRST_NAME LIKE 'T%'. Wrong. It requests every single record in the table. You probably think I mean: SELECT * FROM EMPLOYEE. Nope, even worse. It iterates over the primary key and issues one select per row. This swamped our database a few times.
In the end, we gave up on Access and wrote a perl/web front end.Re:If you're the DBA... (Score:2)
No, you don't have to give the data surfers much access. If all they want is reporting, you could limit them to SELECT privs on relevant tables. But they can still bring the database to its knees with enough SELECTs, especially if they're burdensome SELECTs. You could create a view that 'hides' the join across two tables, but you can't stop the user from selecting heavily from that view. Access has several modes of misbehavior in which it spews a high volume of SELECTs. Also, last time I checked, MySQL didn't have views.
Even if you eliminate the join issue, Access still won't send a proper SELECT that lets the database do the filtering. Rather it will suck the entire table across the network and do the filtering on the client side. A really disastrous design decision.
The bottom line is, above a certain level of size/complexity/value, you have to have separate 'production' and 'data mining' databases. Access is not the only reporting tool that can threaten the performance of a databse. Lots of homebrew Perl scripts can be just as dangerous. A production database should preferably be protected from arbitrary SQL queries.
really? (Score:2)
Why should he bother to learn MS-SQL? For all the money he spent on it, it should'nt require all that. If it does, he might as well use the free standard.
Re:Don't weasel around the boss (Score:2)
--
Re:That's a rather idiotic idea (Score:2)
PostgreSQL isn't a GNU product. It's distributed under the UC Berkeley license instead. Besides, this thread started on the topic of how worthless MySQL is for complex databases, so someone had to pipe in with alternatives.
Both Oracle and Microsoft prohibit vendors from publishing benchmarks using their names without their prior approval. The original source [greatbridge.com] does, however, show the benchmarks with Oracle and Microsoft's offerings marked as Proprietary 1 and Proprietary 2. However, on the section of how the benchmark was done [greatbridge.com], they list among other things, the version of the software the used, with "Proprietary 1" being at version 8.1.5 (probably Oracle), and "Proprietary 2" being at version 7.0 (probably Microsoft SQL Server). The amount of 'tuning' they did for PostgreSQL is quite a bit more than they did for any of the other vendors, so it's entirely possible they might've had slightly higher performance (especially on the TPC-C benchmark, where PostgreSQL, Proprietary 1 and 2 were neck and neck with the three products still tying at 100 users. The test probably would've been more interesting with 200 or 300 users, since they probably would've started to deviate a little).
Just about the only real features that are missing from PostgreSQL that it's competitors have is replication and full text indexing.
Re:That's a rather idiotic idea (Score:2)
So if you say it's a rip-off, then yeah, I guess you could say that, though it was consented (though I'll bet Sybase regretted it), if that makes sense.
Ask for forgivness (Score:2)
Re:MS themselves say DON'T! (Score:2)
Basically we've found the following when it comes to stability:
OS:
BSD
Sun (SunOS Solaris)
Linux
NT
DB:
Oracle
DB2
MySQL
MsSQL
These are general stats collects from several groups at large midwestern telco over a period of three years. Generally speaking NT bases systems like the trouble Ticketing and some minor ordering front ends that are MS based all had tracked down time of at least 3-4 times as great as the Unix systems.
That being said, MySQL can be used fine for production, but it's qualified. Although ROW LOCKING is now possible with MySQL we'd like a little shake down first. We've found MySQL works great when you have a lot of similar SQL queries. Storing stats for instance works very well on several gigs of data a day. On the other hand, I wouldn't count on it if you had a lot of interactive queries. Oracle and DB2 does this better. That being said a lot of performence issues can be taken care of with good programming. Creating temp tables, and good use of unions and joins. Recently I saw an perl programming write some statics programs that had queries that took 5 minutes to run per data set. After going through his code the same data could be ran in less than 20 seconds with better queries.
I think it's importent to note that dispite Oracle, DB2, and MsSQL scaling better, we have never had a MySQL fail for software reasons. Only hardware. And even with those hardware fails, if the HD was still there, the data was too. That's more than can be said with Oracle, DB2, or MsSQL.
Re:That's a rather idiotic idea (Score:2)
And that's a rather idiotic blanket response. In fact, for many Web applications, MySQL will outperform any major commercial database engine. This is because MySQL simply cannot be beat for heavy-read database performance. So the question for the backend is really: What kind of transactions do you need to support and what is your budget? If you already have the licenses or if you have some decent transactional needs, then Microsoft SQL is a good answer.
As far as the client end goes, why the hell is a database needed on the client? Access is NEVER an answer for anything, except maybe as a toy for learning about databases. As I heard someone say about C++ once, if Access is the answer, then it must be a very strange question.
Re:MS themselves say DON'T! (Score:2)
Amusing excerpt:
Q222135 - ACC97: Using Microsoft Jet with IIS
Amusing excerpt:
Look up the entires for further information. Now admittedly, using SQL Server on the backend helps, but at that rate, you might as well code a VB front end instead of an access one.
Re: (Score:2)
Access frontend? (Score:2)
Thats just sooo stupid for so many reasons
If you can use a database of your choice on the back end , cool. But is you have to use a MS product for the front end you need to explain to your boss that it should be VB.
Access is horrible to work with, and it is not very easy to get low level with, which is important if you like to tweak your system for max performance.
I have done lots of access work, and VB work and I have seen every wrong thing that can possible happen, and using access as a front end is always the biggest mistake. Unless this is for less then 15 users, then it would work until you ned more useres. If you can choose your back end, try informix. I have yet to see a database that can come close to its speed with large database's.Plus, you can get a free copy of informix for linux. CIAO
Re:ODBC with MySQL (Score:2)
I can do anything with a web page that can be done with a VB GUI.
Until you see the price tag (Score:2)
Plus it has tons of bugs: Views essentially dont work, The error reporter says thing like "General network error" for a syntax error, and its pretty easy to cause it to crash. If you try to use ansi outer joins, aggregate functions, and subqueries together it craps out. A buggy stored procedure can freeze the whole server up.
Its stored procedures cannot return rowsets to other stored procs, and moving from 6.5 to 7.0 is very difficult because it wont transfer identity prorerties correctly.
Working on budget software at a government contractor I developed for MS SQL SERVER versions 6.5 and 7. (7 is alot better but far from perfect). I think I ran into every major bug in them. MS support was useless- their knowledge base simply told us it was a "known issue".
Now MySQL isnt nearly as feature-full as either, but I prefer posgresql myself. As soon as they get outer joins working I'll never look back.
Re:Don't weasel around the boss (Score:2)
http://208.160.255.143/pgsql/pgsql.exe
Re:Until you see the price tag (Score:2)
Views essentially dont work,
I use views all the time, never seen one that didn't work properly.
The error reporter says thing like "General network error" for a syntax error
Wrong. I would say MSSQL's error messages are above average in the software world for descriptiveness. You only get the "General network error" messag when there's... guess what... an actual NETWORK ERROR. Not too confusing from where I sit but hey, YMMV.
If you try to use ansi outer joins, aggregate functions, and subqueries together it craps out. A buggy stored procedure can freeze the whole server up
I'll have to try and get this to happen. I've never seen that happen before... and I've written a lot of buggy stored procedures.
moving from 6.5 to 7.0 is very difficult because it wont transfer identity prorerties correctly
I only moved one database from 6.5-->7.0 and that was a while back. I don't remember identity field problems. Even if this does happen though, it's easy to force the identity value for each table. Pain in the butt, but shouldn't take more than about 10 seconds per table to force the right value. And it's not like you need to migrate every day- should be a one-time thing.
Its stored procedures cannot return rowsets to other stored procs
This true, and it's a pain... but you can get around this by storing the rowset in a cursor and/or a temp table or just using output parameters for the innermost SP's. (yes I know temp tables and cursors are expensive).
After about three years of MSSQL 7.0 use I'd have to say it's an awesome product, honestly. Stable, fast, and incredibly feature-rich. I've been keeping an eye on PostgresSQL tho. I think that's going to be a match for MSSQL pretty soon, especially since MSSQL is overkill for most user's needs.
http://www.bootyproject.org [bootyproject.org]
This is actually very easy. (Score:2)
Re:odbc. (Score:2)
In other words: yes, go for it. It works. And in the meantime, try to convince your boss NOT to use Access as a frontend, but Visual Basic. You'll get a much leaner and meaner application, and it's just as M$. Access as a front-end is a dumbed-down VB.
How About Interdev? (Score:2)
Bonus points! - The boss could work from home.
In Fact, you could sell the boss on this, saying that this is what you use instead of Access if you want to be "really serious". Acess is for the low end business, and you need the MS industrial products, etc.
Re:Why? Oh God, Why? (Score:2)
1. He already said he hasnt tried ODBC, but also pointed out that he wasnt willing to by asking us to first.
2. Their workplace is happy on Win32/MacOS. They are unlikely to fire their staff because they dont know what their boss feels is an inferior OS. (Not neccesarily my opinion)
3. Solid transaction support is a *must* have for anyone running any sort of financial application. It *has* to pass the ACID test, with no exceptions.
Pertaining to your points:
1. SQL Server comes free with Win2K
2. FUD.
3. True. But not neccessarily relevant once you may have to possibly take into account my point #3.
4. The boss SPECIFIED the windows clients, this means the duct tape is connecting to the db. Remember, he has no choice about the client, so whatever back end he chooses *has* to work well.
5. You can write stored procedures to back up *any* SQL database to file or to another SQL database. Its not *that* hard.
6. The reverse is only seldom true because once they know linux you no longer classify them as a Win32 tech.
7. Cant argue there, that's a very good point.
8. Companies need accountability, and paid-for support that will be there at 3am in the morning "until its fixed". Not someone on IRC that says "I'm tired, I have to go to bed". It is foolish to ignore a fast growing OS, but it is much more foolish to ignore your bosses demands. If 90% of the office knows Windows, then it is by far better to use windows than to rehire (more expensive) unix people, or pay for (Expensive) training for the windows people (who may or may not "get it")
Sometimes the "right thing" is not always clear. I'm not saying that you're wrong, or that the other guy is right, but please look at this from a non-defensive position. There are clearly more things at stake here than chooising a "free" database.
---
Re:That's a rather idiotic idea (Score:2)
Thank you for proudly waving the GNUflag in our faces. Pity we're not talking about PostgreSQL.
btw, if Oracle released a report stating that they had benchmarks proving that their DB was the best at everything, but you couldn't actually see those benchmarks, would you give the claim any credence? If not, why should we trust someone else's rumor? Just because it says good things about an OS application?
That's hypocrisy, my friend.
extending SQL (Score:2)
Not to defend the practice, but it was my understanding that this was pretty common. Don't Oracle and Sybase extend SQL as well?
Re:We do this in some cases (Score:2)
Access95 served over the web with PHP & apache (Score:2)
We bought one copy of 97 to test with it and installed in on out NT 4 server along with Apache and PHP. Once everything was running properly, I just fired up the ODBC driver and everything worked perfectly - a little slow since I've never tweaked it or gotten rid of IIS. Far-flung employees can dial in and check in via a browser. Access as a client over a phone line is a nightmare.
I hope it works best for you. If we were starting over again, I'd seriously consider using front-to-back opensource. But Access clients allow you to edit several records in a single step (without refreshing the page twelve times) which makes users happy.
And as we all know, happy users is what this is all about. [ridiculopathy.com]
I use MS Access as a front end... (Score:2)
The big advantage is that I don't have to train people to use a new program, and I don't have to write a new script every time somebody comes up with a new problem, since Access will generate SQL queries (albeit not good ones, but this a very small DB).
What we are actually doing is having our users access a local copy of the database and doing a daily synch with the production DB. This prevents excess load on the web server, and prevents them from scrweing shit up.
Re:That's a rather idiotic idea (Score:2)
Sybase have recently released a new preview with an inbuilt xml-db - looks pretty cool if you want to avoid shredding inbound/outbound XML into relational tables, not sure if they support Quilt tho....
Re:PostgreSQL via ODBC (Score:2)
Support for outer (left) joins. I mean, I want to be able to do a
SELECT table1.x, table2.z FROM table1, outer table2 WHERE table1.y = table2.y
or,
SELECT table1.x, table2.z FROM table1 LEFT JOIN table2 ON table1.y = table2.y
rather than having to resort to something stupid like this:
SELECT table1.x, table2.z FROM table1, table2 where table1.y = table2.y
UNION
SELECT table1.x, NULL as z FROM table1 WHERE table1.z NOT IN (SELECT z FROM table2)
I mean, come on. PostgreSQL is fantastic because it supports transactions and triggers and just about every other feature that I REALLY want, but it lacks something like outer joins, which makes it difficult for me to work with.
At the present time, my company's using Informix for some stuff, MS-SQL for others. Porting my app to be able to work with PostgreSQL would require some of the above to work.
Re:Why? (Score:3)
Unless I'm wrong, you don't get MSDE included with the normal version of Access.
--
Re:Not really (Score:3)
Like the people who compain about NT crashing every 3 days, you are only demonstrating your incompetence.
If you don't have the slightest idea how to tune MS-SQL, don't advertise the fact. Just keep your mouth shut and maybe learn about the system that you're using.
Cheers,
--Shoeboy
Be an advocate, not an a****le (Score:3)
It shouldn't mean leaving your job to do what you believe in.
It's fairly trivial to convert a set of access tables and queries to SQL create statements that will re-create your design in MySQL, so...
Design your database in Access. Design it well - Get the tables right now and you will save yourself a lot of trouble.
A bad design in Access won't be any better in MySQL, trust me.
Be patient and do what you're told - do it in Access. When you design it, keep in mind that you might be upgrading to MySQL. Find out where it might break and avoid those areas.
Find out the advantages to using MySQL and promote them when the time comes. One example would be distribution of the data over the company intranet. Explain that web-based reports can save you installing Access on everybody's machine. In my case, that was the decision point - The company had not bought licenses for everyone to have Access on their desktop. Explain that a switch to MS SQL Server will also require client access licenses. Explain that MySQL can be had for free. (Actually, don't say 'free' - say 'MySQL doesn't require CAL's for the clients and will do what we need.')
Remember that MySQL can be had for NT, too. That may sit better with the PHB's.
Write some VBA to create MySQL create statements from your Access tables. Attach the new tables using MyODBC. Move the data from Access to MySQL. The other developers and your boss will be more comfortable seeing their data as familiar Access ODBC-linked tables than they will seeing it as text output on a terminal screen.
Write documentation that Windows people will understand. Do a newbie howto that tells exactly how to create the database and build the tables, step-by-step. A lot of the fear of using open source tools is that they can't find people who know it. Make your docs such that any MCSE can install and administer it. Burn a CD that has all of the required binaries and a script that will install everything.
You'll probably have to downplay the Open Source aspect of all of this. Show them that to use MySQL, they don't have to abandon Windows. Just let them know that they are choosing a robust, stable place to put their data that will work on several different server platforms.
Also, keep in mind that MySQL may not be the right tool for the job. Be prepared to use whatever is best to get the job done well, be it Access, MS SQL, MySQL or whatever.
Good luck!
Cheers,
Jim in Tokyo
Why Access? (Score:3)
The problem is that Access (W/o sql-server) is actually less scalable than FileMaker Server. I know this because I run into people who are living in the crashed ruins of both Access and FileMaker projects -- it's a good part of my business.
In the application development domain, most people will end up taking FileMaker further than Access. This is because FileMaker is not a relational database -- it's an easier model for non-expert database designers, more forgiving. It's usually possible to recover failed homegrown FileMaker solutions with some general business application expertise. Similar Access solutions are usually a total loss.
Access is really a gateway drug for MS-SQL and VB. It's very well tuned to give people in the early stages of development positive experiences, but then it breaks down as performance requirements increase and the application increases in complexity. The solution to this is MS-SQL (or another client server database) and to hire an experienced business application developer (and possibly a platform change).
It's not like you can't create Access applications (using the SQL Server back end) that are scalable in complexity and performance. It's just that in practice the successful Access "applications" I've seen are personal or small departmental data entry systems of very limited scale and purpose.
Personally, I use Access for lots of "quick-and-dirty" kinds of things, such as doing data conversions. I think it really shines there (aside from its tendency to pessimize queries to external data sources). I would probably not use it for serious business application development. If you truly have outgrown FileMaker, then you should turn your attention to tools that are designed for professional application development, such as Delphi, PowerBuilder and VB. Actually, these days given my druthers (which as a developer you seldom have) I'd use Java, or for some applications Zope and Python.
I sympathise with Daniel's boss. Microsoft looms large in the imaginations of Mac enthusiasts -- implacable, evil and undefeatable. Implacable, maybe, but evil is questionable and undefeatable is certainly not true. It is simply not the case that there is no other way to survive but to go completely into Microsoft's embrace. It's just that a lot of the creativity that made the Mac platform an exciting place to be in the late eighties has moved elsewhere. Remember getting the huge stack of floppies of incredible freeware applications from your user group?
Where has all that engergy gone? You should take your boss on a tour of sourceforge. Daniel should take his boss on a tour of SourceForge. The difference now is that the free software/open software movements are not a single corporate entity that whose air supply can be squeezed off. They're more like a highly opportunistic fungus that spreads around attempts to control it and leaves spores (source code) where it has been extirpated.
Re:Don't weasel around the boss (Score:3)
- - - - -
politics != good software (Score:3)
How many times do we have to tell the "pointy haired boss" that politics does not make good software?! You need to impress upon your boss the fact that all marketing and promises aside, Microsoft Access is not a scalable or stable solution!
When will people learn to delegate responsibility fully to the people who know how to do their jobs best? By not trusting you, the knowledgable staff member, on your design decisions, your management is suffering themselves no small number of headaches for the future of their company. By locking you into an environment that you are 1) not comfortable with, 2) do not trust, 3) doubt will fit the bill, and 4) dislike, they are seeding the crop of their own distruction.
Take a stand. Review your software design goals, and research the proposed tools and environments to do the job. Include in your research their proposals, and work to disprove them based on your own knowledges and instincts. If they can't trust you, their developer, and would rather go with what a marketing drone would recommend, tell them to hire the marketing drone to write the software.
On a less general note, my advise about writing RDBMS-based software:
What can I say. Access + MySQL sounds like a loosing combination. Access and MSSQL sounds like a better combination, but I would opt for something along the lines of PostgreSQL and Java (though the client-side SWING sucks ass). If you design the application with at least a three-tiered approach, client-server-database, you will be allowed some flexibility in which direction you can migrate with DB selection and client selection.
Anyway, I have to go to sleep so I can get up tomorrow and program... Good luck! Oh, go check out some of the projects like Enhydra.org [enhydra.org] or jboss.org [jboss.org] if Java+Appserver+RDBMS+web raises an eyebrow or two.
--
MySQL not an alternative to SQL Server (Score:3)
Go with PostGreSQL instead.
--
Re:PostgreSQL via ODBC (Score:3)
I have a stock Redhat 7.0 box with Postgresql running with an MS Access front-end. It works quite well. Use the postgres odbc driver and create link tables in the access database.
The biggest quirk that I have seen it that booleans don't work well, use integers. Access likes to use (0,-1) as false,true. The odbc driver translates booleans as a single char. use a "yes/no" data type in Access and an "int4" in postgres and the rest should be fine.
This system has been up and running for over a year. although, it's not under very heavy use. The secretaries update personel info in the database. They only have to update things once. The web server pulls data from postgres (ala php), so the secretaries update my web pages for me! makes my life easier.
Been there done that, didn't think twice. (Score:3)
One of the guys, who has zero education when it comes to coding, databases, and computeres in general (don't ask me why or how he's a programmer.. I have no idea) managed to whack Access up against the PostgreSQL database via the ODBC portal I had done to it (can't remember how... it wasn't much of a thing).
It certainly isn't a revolutionary idea, people do it all the time... it's a two step process:
Setup ODBC to the database
Setup Access to hit an ODBC source (doesn't matter WHAT it is)
Yes, you don't want an "RTFM" post but really.. that's what you'll get
MS themselves say DON'T! (Score:3)
Re:Don't weasel around the boss (Score:3)
I agree that MySQL isn't ready for primetime yet, but it isn't the only open-source free RDBMS.
Why? (Score:3)
If you really have a problem using MS products, you should find a job where you are able to develop on an OS platform. Even though I tend to use more MS software than I have to, I understand where you are coming from. It is much easier and more efficient to develop a DB front end using Perl/DBI than Access/VBA.
Lenny
We do this in some cases (Score:3)
That's the only major downside to this - people who work with Access aren't always used to thinking that thousands of people will be affected by their data changes in real time, so we don't give this functionality to all client.
It's also nice for them to be able to create their own reports based on live data from the website, rather than having us build web-based reporting tools. Yes, it's nice extra work, but when you don't have time and/or they have a budget, letting clients develop things how they want with their own tools is a nice option.
Re:That's a rather idiotic idea (Score:3)
But... if they don't need it, why spend the money? We just completed work for people who bought SQL2000 and 2 W2k boxes, THEN brought in someone to build the website, before it was specced. We built on it, and yes, it worked fine, but for their needs, ONE (maybe two) Linux boxes with MySQL would STILL have been overkill. I have 1 box handling 2-3 times their load, and it's a 300mhz with 128 megs of RAM. They've got 512 meg systems, dual processor 750 mhz, RAID, etc.
Again, nothing wrong with SQL Server, but it's overkill in many situations. We prefer to inform clients of their needs first, and make purchase recommendations after needs analysis, not before.
If you're the DBA... (Score:3)
If you're the DBA and you've been given the responsibility of implementing the data storage at your company, you should be the one who decides what system is used.
Gently explain this to your boss. Tell him you understand that he may have a preference toward Access, but you know from past experience that Access will not meet your long-term needs and you recommend something different.
If your boss still insists, it's time to move on. You work for a micro-manager and that's the pits. Trust me.
--
Re:Why? (Score:3)
--
Why not Interbase? (Score:4)
Also if (which I doubt you would get any from M$ for free) free support isn't a concern then the downloadable version of interbase works quite well. I'm currently redesigning a project from paradox to interbase. Access like paradox is a non intellegent database which requires all work to be done on the client side. The SQL server has intellegence on the server side. The other aspect of a SQL server is that the users don't have to have any access to the directory where the database actually is. I have had users accidentally delete tables before since they have to have read/write access to the tables.
Depending upon your project MySQL could be just fine, it can be run on NT also. I think if you look at the requirements of what your company needs, and which database would better fill those needs, that would make a better argument for the M$ for everything mentallity. Business oriented people will be more impressed by the business side of the argument than the technical aspect.
Don't weasel around the boss (Score:4)
1) implement with Access like the boss wants or
2) find a better job where you can use Linux
This is not a troll, or a flame, or offtopic. I'm serious.
Things to watch out for. (Score:4)
1) Make sure the ODBC driver uses cursors. If not Access will attempt to pull all data from your tables for a simple select queries. This is especially true in forms bound to tables (a bad idea in the first place).
2) the default setup of access runs queries in a case insensitive matter. Make sure you turn on the case sensitive option. Do this even if you go with ms-sql it will make migration easier when you ditch it later.
3) Make sure every table has a primary key and the index name of that primary key sorts alpheitcally first. Name your primary keys AAAAAPkey_tablename or somthething.
4) put in a timestamp field in every table it helps access out.
5) Keep your table names relatively short. Access and SQL server let you have very long table names while Oracle, postgres, db/2 will limit it. If you want to upgrade your sql server later you will be glad you kept your table names short.
6) On a similar note don't put stange character in you field or table names. Don't name objects fax# or discount% also don't use a number as the first character of an object name. Access will let you but your dabase might not. Basically it's best to limit yourself to alphanumerics and maybe the underscore.
7) Make all your table names uppercase. This is not strict but it's a good idea. If not at least try to keep a good method for capitilization and stick with it.
8) Try not to depend too heavily on stored procedures. Although they can buy performance they make switching databases very hard.
Re:That's a rather idiotic idea (Score:4)
Re:MS themselves say DON'T! (Score:4)
It amuses me how the same people/companies that wouldn't use Word for creating a thousand page catalog, and wouldn't use Excel to write a corporate accounting system would, in fact, use Access to create an 'enterprise' database.
Except that isn't what is being proposed. Access is just being used as the front end. IT will work fine for that (as I can attect as we have numerous dbs running with an Access front end and a MSSQL backend. Access is definitely not good for multiusers dbs, unless you have a backend to it.
Acces and AUTO_INC or default nextval('seq') (Score:4)
Imagine you have an order entry form, with the top half devoted to order related fields and a sub form that has the line items for the order. Now both the main form table and subform table have pkeys that are auto_increment. In plain old access this is no big deal, but with access/(odbc)SQL you have a big problem.
According to the MySQL mailing list and the MSKB, this is because Access will re-select the data it just inserted to find the row it THINKS you are working on. That's how it get's the database default fields to take effect and the auto_inc fields. Since, for example, you might have many orders with the exact same order line information, it may or may not find what you want in that subform. Same thing for the order header, if it's a stock order from week to week, then it may not find it.
Their solution is to make every form that adds records have a field that inserts 'now' so Access can find your row better.
An ugly kludge if you ask me, but I worked with it. And when I was done I started installing ODBC drivers on every machine and making sure the DSN was right and making sure the proper version of Access was on the machine. This was the other big problem, the amount of software required to make the system work on the client side, it's un-believable. So I've abandoned Access/anySQL and now work with just web-based applications. Only software required is a browser and thanks to MS and the popularity of the internet, that means everyone will have it in one form or another. It also means people can work from home, the office, vacation, whatever.
The only drawback was rapid app development, sql forms and even forms in general require so much bitch-work to get working it's just frustrating. So I've built some perl modules that handle SQL forms generation, binding to fields, verification, and insert/update/delete functionality from data descriptions. The bonus of this is I can make the updated forms definition a module and re-use it. Now, in access, if they say "we want 1 more decimal of precision here..." you've gotta find the damn field on every form and change it there, no re-use. The only thing missing (and actively being developed) is a reporting module to generate text/html/pdf/etc reports.
Re:not a "'ODBC RTFM' flame"... (Score:4)
I'll drink to that. I don't know what exactly Access does, but it fails miserably with even moderately-sized tables. We use Oracle, and figured it would be nice to provide an easy-to-use interface for staff. So we bought Access, installed the drivers, and linked the tables. It would take as much as 20 minutes for windows to open; searches and so on would take longer than anyone wanted to wait. None of the tables in question is more than a few million records, which in any case should be immaterial since you'd expect the front end to use the back end to do the heavy lifting. My best guess was that Access rolls through all the data itself, totally missing the point of why there's a real database at the other end of the line.
Anyway, I ended up having them whip up a PHP/web interface instead, and everyone's happy now.
Re:Don't weasel around the boss (Score:5)
MySQL doesn't support all of SQL, or all of ODBC, and Access will try to do things that it will not allow.
Stick with SQL Server
(says the Linux guy)
- - - - -
My Experience with Access and MySQL (Score:5)
I have actually looked into the feasibility of doing something like this before, and I think you may run into some problems. The main problem is that what Microsoft calls SQL in Access is very misleading . . . while it is structured, and is a query language, it isn't SQL. The Access version of SQL really just gives the ability to have text based representation of what can be done using the GUI queries which are needed to compete with Paradox and other proprietary databases.
In addition, Microsoft has extended the MS-SQL language to use its own proprietary extensions. Microsoft has taken the attitude with Access SQL that they take on everything else - they program what they want and the standards be damned.
The major differences between Microsoft Access SQL and ANSI SQL-92 are listed in a table on page 190 of "Access Developer's Handbook" by Litwin, Getz & Gilbert from Sybex.
Here's a quote from the above book, "Access SQL is a hybrid SQL. It differs considerably from each of the SQL standards and doesn't completely support any of the ANSI SQL standards. It lacks large chunks of the standards, particularly in the areas of security and cursors. Sometimes it supports the same functionality found in one of the standards, but with a different syntax... In other cases, similar functionality is provided elsewhere in Access... Finally, Access SQL has some useful extensions that are not present in any of the standards..."
Overall, you may have some difficulty using Access with MySQL. If your boss is making you use MS on the frontend, it really will save you some trouble to use MSSQL on the back. If you do decide to go ahead with MySQL, my only advice is to make sure it is a well-researched decision. If you don't know exactly what you are doing and it doesn't work, it will just bolster your boss's attitude that all linux / open source solutions are problematic.
Devshed just did an article on this... (Score:5)
"Learn it from start to finish. Installing MyODBC, creating a new data source through the ODBC Data Source Administrator, linking a MySQL database into a new MS Access database, and finally updating the MySQL database through an MS Access GUI."
Enjoy
If you have to use Access... (Score:5)
ODBC Socket Server is an open source database access toolkit that exposes Windows ODBC data sources with an XML-based TCP/IP interface.
It has clients for PHP, Perl, C (in Windows, Mac, and Linux), Java.
Why? Oh God, Why? (Score:5)
I have no clue what kind of application you have -- what the nature of your data is, or the nature of the front end is. I have absolutely no idea why you think a web browser front end, PHP middleware, and MySQL back end is the superior solution. (Or, perhaps by PHP front end, you were refering to that GTK/PHP toolkit mentioned on Slashdot a few days ago, and you want all the users to have a Linux box on their desk. I don't know.) I have absolutely no idea why you believe Microsoft SQL Server and a MS Access front end to be an inferior solution.
What I do know are these things. MySQL and Microsoft SQL Server are two vastly different applications. As a DBA, you are obviously aware that on a technical level, Microsoft SQL Server is the vastly superiour database. In a shop that is almost entirely Microsoft, with only a few Mac's, the MS SQL Server is going to vastly easier to keep running, unless you plan on hiring consultants or tech's dedicated to keeping the only linux box alive.
Face it... they're on completely different planes -- the only place that MySQL beats MS SQL is on speed, on only a subset of the queries that MySQL is able to perform. You won't find any other comparisons of the two databases, becuase MySQL simply will never, ever be able to do any of the things that MS SQL does, and does well. A fair, unbiased consumer reports comparison of the two databases would be nothing but hundreds or thousands of checkboxes that give MS SQL two or three or four stars, and give a little "N/A -- not available" mark to MySQL. It would be a joke.
I'll freely admit that there are many places why MySQL is useful. The standard Linux or BSD box, running Apache/mod_perl/PHP, with a MySQL database is a tottally rocking deal. If you're a decent Unix hacker, it's easy to keep running, it's extrodinarily flexible, it's easy to learn to use, and it's fairly well documented. For 98% of the websites out there, it's plenty good enough. You can even set one up in your office on a spare pentium 75, just to try stuff out before going live with it. I love the combo, and it's what we use on a lot of the sites we develop at work. But for the people who need it or want to pay for it, we use a real database. MySQL is a great database for developers who are aware that it is not a great database, and can explain why.
But for running a dedicated database machine, hooked up exclusively to a group of MS Windows clients running a MS Access front end, in an office where the DBA isn't smart enough to make ODBC work, and the DBA's boss only uses Mac's, I can't think of a single reason you'd want to use MySQL. Not one. Having a wierd box in the corner running a wierd database on a wierd operating system that only one guy in the office understands, duct-taped up to a bunch of Windows clients, seem like the perfect recipe for a maintenance disaster a few years down the road. What a crappy idea.
PostgreSQL via ODBC (Score:5)
Re:Windows ODBC Driver for MySQL Server (Score:5)
http://www.iserver.com/support/virtual/mysql/odbc
Amazing what a Google search can turn up is it not. Just a hint Most of us will *never* think of anything so unusual that it is not already on the web. Do a search first and then ask questions.
That's a rather idiotic idea (Score:5)
You can hate Microsoft as much as you want, but MS-SQL is a whole hell of a lot better than MySQL. There's places where all these wonderful OS applications don't work nearly as well as a proprietary solution, and databases is definitely one of those places.
MySQL is a great DB for fast read access where things like row locking aren't very important. Great for the web when you don't want to spend a lot of money. But if you've already got SQL then using MySQL is just plain dumb. SQL on NT will out-perform MySQL in just about every way. Not using it just because you don't like Microsoft could get you fired, and IMO it would be justified.
Access can connect to/front-end for a MySQL DB (Score:5)
As an extension of the above, and table creation must take place in MySQL and then a link in Access created. Table mods must also be performed in MySQL afaik.
I haven't done this in ~2 years, but that's how it worked then, so take it (above comments) with a few grains of salt.
--
Never meddle in the affairs of dragons,