Does anyone know of a way to make Excel 2003 push changes to a MySQL database?
Currently, we're using Excel 2003 for keeping track of a big bunch of interconnected equipment (actually, an entire electric power distribution system with all the hoo-ha's that hang off it.) Quite frankly, using a spreadsheet for this sucks and I'm sick of it, so I want to convert it over to a Real Database like MySQL.
The gotchas are:
The people who are using it aren't overly computer savvy. Using Excel to edit the MySQL database saves them the pain of learning something new.
We don't have a license for MS Access, or I'd use that instead.
I don't have the time to roll my own custom app.
I've already grabbed the MySQL ODBC driver and installed it, and importing data from MySQL to Excel is a breeze; but there's no obvious way to to the reverse, and push changes in Excel back to MySQL.
There are (at least) two possible approaches here.
Use a MySQL database and, as you suggested, use the ODBC driver to update the database. Using ActiveX Data Objects (ADO) can let you accomplish this. See here for details
Alternatively, you can create a Microsoft JET database and use that instead of MySQL. This can be done using ADOX to create the database - see here - and then ADO to update it.
Both ADO and ADOX are available on my standard Office 2003 install (which does not include Access) so hopefully your system will have them too.
As a fallback if these aren't available, you could look at Data Access Objects (DAO) - the predecessor to ADO - but ADO seems a lot easier to use to me. DAO details are here
#Roland Bourman's comment (which would deserve to be an answer in itself) is a very interesting approach. If you're not a VB expert, you could mabye even do the pull/push outside of Excel on script level, pulling the data from mySQL into an excel sheet before opening Excel (easy) and writing it back after closing it. This could be done using a variety of tools.
Related
I have an ACCESS database that I'm using to test migration to SQL Server. It has one local table; no linked tables, forms, queries, or reports. One site said to use the open the Database Tools tab, and click the Access Database icon in the Move Data group. When I do, it tells me that the database must be split. How do I let ACCESS know that the database has been split?
The move data features up to Access 2010 ALSO had a feature to move data to SQL server. However, due to SQL server always changing and having new versions that come out at "different" times then ms-access?
the feature was deprecated, and versions of Access after 2010 don't have the move to sql server anymore.
If this is just say a simple single table, then it you can use SQL server studio to import the table. (but, you lose PK settings, and indexing, and relationships (assumes you have more then one table and related tables).
If you looking to migrate a lot of data, and a lot of tables?
Then it is high recommended that you use the Sql Server Migration Assistant for Access. (SSMAA).
It is a separate download. You can find SSMAA here:
Information on this tool, and download links can be found here:
https://learn.microsoft.com/en-us/sql/ssma/access/sql-server-migration-assistant-for-access-accesstosql?view=sql-server-ver16
While the tool has a learning curve, it is well worth the efforts for any type of serious data migration from Access to SQL server.
I just wanted to know if we can access excel spreadsheet in the same way like we access MySQL database over the internet. Actually I am trying to make an application that will run on multiple computers simultaneously and all the computers will be able to edit or retrieve data on the excel spreadsheet located on the server.
You can use Windows ODBC to create a Data Source that can be accessed like a rational DB. ODBC has a special driver for Excel files, among other formats (Access, CSV, Plain text, ...).
You can access ODBC Data Source Administrator from the Administrative Tools in Windows Control Panel.
Generally this is a bad idea. You can definitely access information in an excel spreadsheet from vb.net, but it can be somewhat buggy, and small issues turn into big issues. You're better off to use SQL Server Express. If you decide to continue to use Excel, you may want to stick with VBA. It's built into excel and although it still may cause issues, it will probably be a lot cleaner.
In Access 2003 I used to import special xls files provided to us by a third party. I used ADODB for this, which worked perfectly.
ADODB is no longer an option in Access 2007/2010, and I don't think you can "query" a spreadsheet using DAO or ADO.
So, are there any alternatives?
I don't think you can "query" a spreadsheet using DAO or ADO.
You can indeed query an Excel workbook using ADO with the OLE DB provider for Access (Jet, whatever). See this MSDN article for more details.
ADODB is no longer an option in Access 2007/2010,
That is not the case. I think you must have misunderstood something, which is hardly surprising considering there is a lot of nonsense out there on the interwebs surrounding "ADO vs DAO" in Access.
I'm not exactly sure what happened when ADO classic was introduced to the Access2000 community but it seems that a lot of old-timers were left with hurt egos/pride. The marketing message from Microsoft was in effect, "DAO is now the old way of working and ADO is the new." In a deliberate move by MS,, new engine features were generally only available via ADO.
As is often the case when entrench positions are threatened, there was a counter-movement by long time Access+DAO fans. This often took the form of, "throw enough mud and some will stick." People newly arrived in AccessLand would be confused by the mixed messages. In the newsgroups, aspiring Access MVPs emulated existing Access MVPs' anti-ADO stance.
Between the 200 and 2007 releases, the Access product became IMO somewhat stale as regards the engine, responsibility for which had been handed to the SQL Server team, who had for all practical purposes given up on it: their attempts to make it comply with entry-level Standard SQL-92 were thwarted by the Windows team, whose components relied on features that flew in the face of the Standard. The ADO classic team had similarly been disbanded. Visual Basic COM, which effectively shared VBA libraries with the Office suite, was killed off in favour of VB.NET and ADO.NET was born,
The Access2007 team shook things up again. They reclaimed the engine from the SQL Server and Windows teams by taking a private branch. They ditched user level security, presumably because it was too complex for them to maintain. They added multi-valued types that arguably violate 1NF. Brave stuff! While some features could be accommodated in ADO classic by authoring a new OLE DB provider for Access, others could not. For example, full support (e.g. updating via SQL) for multi-valued data types in ADO would require a change to the ADO classic libraries which the Access team does not own.
Because DAO was owned by Access, the new version (called ACEDAO) got features the new OLE DB provider with the old ADO classic libraries would lack (although ADO was required to use the engine on 64 bit machines). However, what they did not do was to retrospectively fix DAO to accommodate the Access2000-era functionality that went into ADO only.
Naturally, the Access team promoted ACEDAO as first class citizen. Of course, the long-time Access+DAO fans were delighted: "ADO has been deprecated in favour of ADO.NET," they crowed. In truth, the net result is a mixed bag. See this thread for full details.
In your VBA project in Access click on Tools / References then find "Microsoft Excel 14.0 Object Library". This will give you access to all of the VBA Excel objects so you can do whatever you want to the spreadsheet.
As others have said running queries on the sheet is not an option. If you're used to thinking in terms of databases think about running a check on the template to make sure the headings match so you more than likely have a good file you're reading from. Then once you've verified the document setup SQL inserts on the lines with records on them into a table in an Access Database then run your queries from there. Check here for writing your SQL code:
SQL Statement Help
If you want to get more advanced in your VBA if your files are small you could run searches by setting up an object with setters/getters and store the records into a collection class then iterate across it with the data you're looking for.
I do this in some projects where I know the lists are small, gets away from reading/writing to tables when I really just want to read the data and run some real basic calculations like count the number of a particular widget and place the count on a report. Collection classes are great for this. Here's a good link for some more info on collections:
Collections in Visual Basic
Good luck!
Is there a way to version the VBA modules inside an Access 2007 database, or am I just stuck with exporting the code and keeping it separate from the database and maintaining two different copies?
MS Access has a MSSCCI interface which you can connect to any source control system which has a MSSCCI interface. Many of them do. For example for SVN there is AgentSVN or VisualSVN.
Download and install the Access 2007 Developer Extensions, and choose the source code control from your installed SCC providers.
Source control in MS Access uses the Access SaveAsText/LoadFromText methods. All recent versions of Access use a VBA object to hold the VBA modules in, they aren't stored natively in the database anymore, so you can't just export the record holding each module as you used to be able to do.
There are mixed reports about using integrated source control in MS Access. Your milage may vary.
On a historical note, a multi-user, multi-process relational database is ideal for ensuring coherance in source code. According to some reports, the Office 2000 developers were unable to maintain project coherence when using the native database to store modules, and fixed it by using a locked single project object. Possibly missing the fact that Windows 2000 SMB server was corrupting data (fixed in Win2K SP1).
Based on the response so far, I conclude you can't have versioning.
I believe this is because an Access DB code-base is not viewed as a set of modules -- that is, not as interchangeable elements the way code is in many other settings. A truly modular approach increases the requirement for strict control because you must ensure coherence; thus, versioning.
Code in VBA is not handled as agile -- which of course is understandable historically. It's a huge watershed in development approach. So while you benefit from an agile mindset, you won't find it facilitated so well.
NOTE:
In case you're not aware, some key aspects of modular approach are met by separating the app into client and server documents (splitting your database).
I'm trying to create a completely new database from an existing MySQL database, bringing over both data and schema, but so far the only way I've been able to do this is to first import the MySQL database into MS Access, and then into SQL Server 2005? Crazy right? Surely, there is a way that doesn't involve a tedious, custom time-consuming programming, right (perhaps using SSIS)?
A few additions to my original description above:
Its a pretty good size database (easily a few gigs).
I'm working in an MS environment (asp.net, C#)
I'm under a tight deadline so I'm looking for an automated process that requires little to no effort in the conversion process.
SSIS would be the preferred way via BIDS (VS 2005)
Thanks for all the great input!
I believe that using the phpMyAdmin tool you can script the MySQL database structure and data into a sql script. Then you simply run those two scripts on your SQL Server 2005 database and it should, in most cases, create the database and fill it with data. It's been a couple years since I had to do it myself, but as I recall that was the process I used to transfer a MySQL database to SQL Server in the past. You will probably have to alter the structure script to change some of the data types to their SQL Server equivalents, but the data should load just fine once you've got the data types all sorted.
I think you can use SQLYog to generate some fairly standard SQL which will dump out and recreate your db, with data. You may have to massage its output for SQL Server's dialect of SQL a bit, though...
The responses I received were certainly helpful, but the solution it would seem is to do a mysqldump and then run that script from SSIS, massaging the output as needed; however, AFAIK it is not possible to use VS 2005 BIDS to create an SSIS package that completely transfers a MySQL database to a SQL Server 2005 database (data and schema) using Windows Vista 64. I said AFAIK, but who knows the interwebs have much to reveal :)