I have quite a bit of experience with VBA in Excel and have learned that the interaction between VBA and Excel is slow. Thus, you should read and write large chunks of data at one time instead of one cell at a time.
With VBA in Access, I have very little knowledge/experience, almost none. Is the same sort of thing possible, reading and writing large chunks of data at once? Is it as important, i.e., is it possible that maybe it's not as important because the interaction between Access and VBA isn't as slow? I have no idea. Any ideas would be great.
Thanks
It depends on where your data is coming from, if you have it in a format such as CSV or Excel then you can load it as one block and this is quite quick. The same applies to different database formats and ODBC connections, MS Access can process these quite quickly.
In fact there isn't usually much call for reading and writing large chunks of data using VBA at all. Even with some of the most powerful database servers RBAR (Row By Agonising Row) processing can cause a system to grind to a halt. VBA in Access is no exception to this, it's probably very similar to VBA in excel in this respect.
VBA in MS Access is usually used to improve user experience with automation, to speed up complex calculations and repetitive user tasks.
Excel is a spreadsheet, Access is a database management application. You should do a little reading:
Fundamentals of Relational Database Design, Paul Litwin, 2003
Fundamental Microsoft Jet SQL for Access 2000
Intermediate Microsoft Jet SQL for Access 2000
Advanced Microsoft Jet SQL for Access 2000
Related
I just recently started my first job doing reporting and analytical on a project team. Currently a lot of data and reports are sitting in excel spreadsheets and in some database tables. Reports are drawn from this data in a very manual adhoc approach. It would seem that this has/is quickly becoming very problematic as the reporting requirements are increasing rapidly. The project will soon be rolled out more quickly, and our manual efforts won't suffice. Currently we are spending a lot of time manually doing etl like activities, the results are then sliced and diced in excel, and graphs and tables exported for management. After which the process has to be repeated for the next reporting cycle. We need to implement some automation in this regard.
As this is only a medium term project a full blown etl and reporting solution seems out of the question- neither time nor resources permits. Being a fresh graduate I know what has to be done, i just don't know what tools, utilities and software to implement. Google is just confusing me more. Any suggestions? Really feeling like I'm in over my head.
If number of Excel files are in tens rather than hundreds, I would suggest importing them to Access manually, and/or with bit of VBA standardise the data before importing.
Then, you can use Access to make reports.
Essentially, answer to your question boils down to this: Is It Worth the Time?
I believe you really need at least a reporting tool for automate this job, a tool that really covers most of what you need it's DBxtra, it connects directly to MySQL, exports to Excel and it can send the exported results (or a pretty designed report) to anyone by email automatically (for example every Monday at 6:00 AM), the biggest problem is that you point that your data is not fully "curated" for reporting, but if you can implement SQL logic to clean it up then you can automate almost the full processs, otherwise, you can automate the exporting to Excel, do the clean up work by hand, and automate the sending of the report to the managament guys (DBxtra can also connect to Excel directly and create reports from it).
If you want to do it by hand, you can do an application on any .NET language and look up for a way to connect to MySQL (ADO.NET) and export to Excel (Excel Interop or third party library).
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!
I have a table in SQL (using SQL Server Management Studio 2008) that's around 300,000,000 rows. Due to powers beyond my control this lovely table has to be converted to access datebases (plural since there is no way access will ever be able to handle so many rows).
I was hoping that rather than face the rather daunting tast of creating many csvs and importing them each into their own database there was a way to automate the process? Any ideas?
Thanks so much!
My suggestion would be to leave it in SQL server and use an ODBC connection to access it from MS Access
I have an access database/forms, controlled by VBA. Records can be deleted/modified and added. What is the best/natural way to share this database within only 3 desktop PCs? Would network share from one of the PCs would be sufficient and automatically taken care by MS Access? What additional actions in VBA I have to take care of? I'm mostly using CurrentDb.Execute to add/update and delete.
Split the data and application into separate databases
Compile the application potion into an .mde (or equiv in 2007) to keep your users from messing with it, and put it on a share (or you can distribute it to each machine if you need performance).
Put the data db on a network share.
Ob. MS SQL Plug- better yet, convert the data db from MS Access into MS-SQL, and host it on a server and save your self some future pain, because with multiple users, MS Access is known to corrupt its own database from time to time. Even 2007.
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.