[RESOLVED] MySQL Connector

We are seeing some real inconsistencies using MS Access over a LAN. I am hoping to use another DB platform like MySQL. I am totally new to using this platform on Windows so here goes another learning curve. I see that it probably takes the MySQL .NET Connector to run. This means downloading and installing this file not only on my machine, but on every users machine which will be using the interface. The IT guys here are going to have a heart attack when I tell them I need to deploy yet another 3rd party driver. And yes, these are the same IT guys who hate Microsoft and keep telling me to move away from anything to do with M$.

So am I seeing this correctly. I will have to download this ADO.NET driver for MySQL and install it on each and every machine which will be running the app(s) I develop for use with MySQL? Is there anything more efficient than can be recommended?

nothing :)

Secondly to be prompt
M$ is like a ciggratte we have addicted to it because of it's simplicity
even though much stable, secured linux is free ! , the reason is that the Complexity of Linux ?. nOT FOR A LAY MAN the M$ found this secret & survives till Linux over comes this secret.

vlad
i admire it is a very wise decission to go ahead with MySQL.
but go for asp.net ( i don'r prefer PHP SINCE it is a shape less language )

Actually I'm a FreeBSD + PostgreSQL guy. Even though my experience with that is only slightly higher than Linux + MySQL. But this is the only db choice I have here besides MS Access. I think I can make it work but it's not going to be easy.

I have downloaded the mysql-connector-6.6.5.msi and did a typical install on this Windows 7 machine. But now I'm lost. The docs don't really tell me what's next. I searched for mysql.data.dll and seemed to have found the install went into the .NET under Programs (x86). Will be testing this puppy out this afternoon.

no worry
.net connector is pretty straight forward to use

it will be at

Quote:

---

C:\Program Files\MySQL\MySQL Connector Net 6.6.5

---

and for usage documentations is pretty neat
(1) MySQL documentation down load page
(2) MySQL connector documentation down load

Actually for Windows 7 uesers it will be at

Quote:

---

C:\Program Files (x86)\MySQL...."

---

When I installed it I thought I'd read something about it being both 32 bit and 64 bit and if it sensed a 64 bit OS it would install both. I will have to double check this when I get back to my office later today.

And on the subject of deployment...can anyone enlighten me on the process. The MySQL.Data.dll file. Will that need to be copied in the path on each users' computer or is there a central location I can place it on one of the servers?....I have never done this type of roll out before. Or can VS 2012 Express make it part of the compiled exe???

When you install Connector/Net, it gets installed in the Global Assembly Cache (GAC), which is where common libraries are stored. If you do that then that library will be available for all applications installed on that machine. If you wamt to go down that route but you want to avoid the user having to install it themselves, you can look at creating a custom prerequisite package for Connector/Net and then it can be installed with the tick of a box, just like the .NET Framework and SQL Server Express, amongst others.

If you don't want to use an installer for your app, or even if you do, you still don't need to install Connector/Net to the GAC. When you add a reference to an assembly in the GAC, it is not copied to the project output folder by default. You can change that in the properties of the reference and then, each time you build, the MySql.Data.dll assembly will be copied to the output folder along with the EXE. You can then simply copy both to another machine and it will work. What that means is that multiple applications connecting to MySQL need multiple copies of the assembly and each application will have to update its own copy to get upgrades and bug fixes.

I too have started noticing strange behaviour in MS Access databases (Using the oledb JET in a .net application)

The exact same code has worked fine for many years but recently I've noticed that writes to the database are sometimes taking many seconds to be properly committed to the database.

For example a transaction updates 3 tables and commits successfully. The application then opens another window to read back some of the data and it gets the old data not the new data. Come back 30 seconds later and some of the data has updated while other data is still old. Come back 10 minutes later and all of the data is finally readable. This is quite rare but I notice it every couple of days. Some strange caching in some recent update to Jet I think.

I'm making a new version of my application for MS SQL Server - not because of the above problem but because some corporate users want to use my application against SQL Server over their wide area intranets.

But while doing that I've been thinking about dropping the old JET database for my smaller/local applications. I haven't looked at MySQL. I use it for linux websites but haven't thought about using it in a windows machine. SQL Server 'LocalDB' would fit the bill for single user machines but I'm kind of leaning towards "SQL Server Compact Edition" which, like jet, does not have an actual server.

So, I suppose my question now is:

1. Has anyone else noticed strange things with JET recently ?
2. Alternatives. Apart from the obvious (SQL Express) has anyone done anything with 'LocalDB' or SQL Compact Edition ? Or would recommend something else ?

Thanks
Ian

What I can tell you we've noticed around here is that one of the MS Access databases which has been in use for years is very prone to crashing. The mdb file is stored on one of the servers and many people access it simultaneously. The question of course becomes is it the datafile, the MS Access software, or all the network latency we notice on this LAN. Perhaps all of the above. There are times when just by using Access as the interface a user may see the message that the database is not available and needs to be repaired. We then have to go around and get everyone in the company who may be in the database to exit Access and then allow one user to go back in and restart it. Then everyone else can go back in...until the next crash. Doesn't happen every day or even every week. But often enough to be a PITA so I'm trying to build this next app using MySQL. There is also a PostgreSQL db running here on Linux but the IT guys prefer me to use their MySQL setup.