Although I've done VBA projects within a single application for both MS Access 2007 and Excel 2007, I haven't automated multiple applications at the same time. The generalized project is to open access, run some update queries that appends data to various tables. Then Excel needs to get the data. Some formating changes are needed in Excel, such as grouping that doesn't automatically change the date range. Finally, I plan to build it out such that the excel file will be emailed automatically.
Some parts of this are clear how to accomplish it, such as Excel will be getting the data by ODBC from Access. But where should the master VBA live? I could have a button in Access that would start running Access VBA, but is it a good practice to have the Access VBA start manipulating Excel? Does that make it difficult to debug?
To get started from Access, add a reference to the Excel object library. Then use the object browser to familiarize yourself with how the Excel object hierarchy looks from within Access. It is going to be somewhat difference, because the top-level object in Excel code is implicit (as it is in Access), and has to be explicitly referenced when coding in Access.
The Access Developers Handbook has excellent chapters on automating the rest of Office from Access.
Last of all, it's best once you've coded using the reference to the other app's automation library to help you program, you want to switch to late binding so you can remove the reference. This means not using any of the external library's specific data types (you mostly use plain object variables) and using none of the constants defined in the external library. My production code with late binding usually includes the early binding version commented out, alongside the late binding version.
I think the keywords you are looking for is "microsoft office automation".
Make an application in you favorite programming language that supports COM interfacing and then use automation to do the manipulations in the different office applications.
Look here c# How to access an excel cell? and here How to read data of an excel file using c# ? and Google.
I have recently done something quite similar to this, and have found that I can output HTML with built-in CSS for formatting that loads quite nicely into Excel. I used Access to allow users to build their required output, only opening Excel to display the results. You may find that HTML output makes for nicer emails.
Do all the work in Access VBA. See the following URLs for some sample code
Modules: Sample Excel Automation
Modules: Transferring Records to Excel with Automation
Also note that if you are dealing with multiple versions of Excel late binding becomes a necessity. Late binding means you can safely remove the reference and only have an error when the app executes lines of code in question. Rather than erroring out while starting up the app and not allowing the users in the app at all. Or when hitting a mid, left or trim function call.
This also is very useful when you don't know version of the external application will reside on the target system. Or if your organization is in the middle of moving from one version to another.
For more information including additional text and some detailed links see the Late Binding in Microsoft Access page.
As far as emailing goes there are a number of options at the Microsoft Access Email FAQ
You may put the code in Access, or Excel. In my experience, that is easier to work with than splitting the code between the two (which also works).
If you find that the automation code runs too slowly, you can split the code, so that Access is run by functions in Access, and Excel from functions in Excel, and the master code just runs routines in both. In this case, you can put the master code where-ever you get the nicest user interface for starting things. I've used C,Access,Word and Excel, and where you put the start button doesn't matter a whole lot if all the code is somewhere else.
If your users or maintainers are more familiar with one application, you may wish to put your main or master code there, but more often I find it is better to put the main or master code with the guts of the application, so that I can have no code at all in the other partner.
From the brief description, it sounds like more work will be done in Excel, so I would put all the code there.
Pulling the data out of Access doesn't even need an Access Application object - a DAO or ADO or ODBC object will work (or even DDE), which will be much faster, much more robust, much easier, much better than having both applications open and automating one from the other.
If you start from Access, it sounds like this project will require an Excel automation object. That works well now, but it is still much slower and more fragile doing it with just Excel and a DAO object.
I haven't done VBA for ages although Access was my entry-point into the world of programming. Moving from Access 97 to Visual Basic was easy and I remember that I wrote a lot of stuff using Access more like a VB-form for doing many kinds of tasks (not necessarily database-stuff).
This is the reason why I think you should stick to Access and from there, with help of VBA, do your stuff in Excel etc..
Good luck
Related
I've put together a simple Excel database that performs a few macro functions and I need to distribute this database to a few people - but they cannot see how the macro function actually works (stupid rules I have to follow!). What is the best way to achieve this?
I've done a bit of research and I found two ways:
Password protect the VBA project; but this is apparently very easy to break using readily available tools online (it would be in the best interest to the people I'm sending this to find out how the macros and functions work; so I'm almost 100% sure they will try to get into it.. hence a password protection seems inadequate.
Move to a fully compiled language like C++; my skills are very limited to VBA on Excel and Access so this being the ideal solution; isn't a solution for me :(
Are there any other ways? I thought of having a 'master excel document' with all the macros in that and then send 'children' databases to the end users and have the 'children' databases connect to the 'master' - is something like this possible? By hosting the master online or even sending the end users the master but making it completely inaccessible unless accessed by the 'children' databases?
You can create Automation Add In.
An Automation Add In provides several advantages
Execution Speed : An Automation Add In written in VB6 is compiled to
native machine code which runs much faster than the interpreted VBA
languange.
Security : Unlike an XLA add in, you never distribute the source code to the end users. If your code has proprietary information or
intellectual property value, that remains safely protected on your
own computer. It is never distributed to the user. Your code can
never be compromised.
http://www.cpearson.com/excel/automationaddins.aspx
There aren’t too many ways to protect your Excel VBA code reliably.
You can try to use passwords or VBA obfuscators, but all of that protection is limited. Passwords are easy to break, and obfuscated VBA code can still be traced back and recovered.
The other answer to this question mentions using VB6, but that limits your code to 32bit Excel. Also VB6 can be decompiled by VB decompiler.
Converting your code to a compiled language is indeed the best way to protect your VBA code, but be warned that in this case not all code is created equal.
Converting your code to VBA.NET is a flawed solution because the compiled code of .NET assembly can be converted back into the original source code.
Converting your VBA code to C or C++ is the most effective form of protection, but this takes a lot of experience and effort since C/C++ and VBA are very different languages.
I would suggest you have a look at a tool called VBA Compiler for Excel (https://vbacompiler.com/how-to-compile/). It compiles your Excel VBA code into a DLL file with a click. You do not need any knowledge of C or C++ languages to use it.
If you're still looking for a good way to protect your Excel VBA code from copying or tampering, then you should consider the Excel VBA compiler of XLS Padlock.
Because XLS Padlock offers an integrated VBA compiler that can compile your VBA code into binary code, making it completely secure and inaccessible to others.
it's really binary code and not simple obfuscation.
You open the VBA compiler of XLS Padlock, move some vital parts of your existing VBA code into it (subs or functions) and it compiles live. You can then invoke this compiled code directly from your normal VBA project using dedicated functions.
It's like having several modules, except that some modules are compiled into bytecode and thus secure.
No need to learn a new language C or C++ or VB, nor COM add-ins.
Plus, XLS Padlock can wrap your Excel workbook into a secure shell application, which you can then distribute and even sell to your customers.
It does not create DLL files that must then be distributed among your workbook files (imagine if your other non-tech users lose the DLL or don't know what it is), the software compiles spreadsheets + compiled code into a single EXE file.
It is even possible to add licensing features, online activation if you want to sell your workbooks or control who uses them, while keepking your VBA code secret.
The issue here is ADO connection with Excel - is this still the standard way to read/write excel files within a Dephi XE environment? We're coming up with multiple issues when reading/writing using the ACEOLEDB driver (ACE 12) and this includes
Reading cells with hashtags don't return results
"Invalid Floating Point" when exporting grids.
We've also noticed that there's many versions of the ACE 12 driver out on Microsoft's website (via Access Database driver executables) and they each seem to have different issues with Delphi.
With these things in mind,
Is using ADO with Excel bad at this point?
Does anyone else have these issues and what did you do to resolve them (other than using XLS files instead of XLSX)?
ADO in Delphi is leaning to TDataSet model, which mean strictly tabular data... that excel is not. Each excel sheet has a random cells filled, some of those may constitute quazi-tabular ranges, or may not.
Depending on the installed software you can
1) use Excel application to open XLSX, read the cells and pass them to your program. This is most easy and compatible method, though is noticeably slow due to COM IPC marshalling and switching. There are tricks to fasten it, like hiding Excel window, copying arrays of data instead of cell-by-cell approach and such.
Start exploring TExcelApplication component - http://docwiki.embarcadero.com/RADStudio/XE3/en/Using_Component_Wrappers
2) If you do not want to rely on having commercial Excel installed, you may try reading XLSX files with OpenOffice. Vanilla OpenOffice can only read them though, but some other distro's can write them as well. OpenOffice also exposes external APIs both COM-based and HTTP-based. I know there are Delphi projects of Delphi - OOo interacting but personally did not used them and apart of noting that approach i can say no detailed assesment of it.
3) Microsoft also used to sell Office for Developers or such, that gave you Access and Excel kernels as redistributables, that you could pass with your application and install them and use them. Dunno if it is still feasible though.
4) there is a set of commercial components reading and writing those files directly w/o need to have external EXE's doing the job. While that would be the most fast way to work, it would only support some subset of features (which may or may not be ok for your particular goals) and may have troubles with "future compatibility" as Microsoft would roll out updated versions of XLS and XLSX formats (which again may be of some or none concern to you). Like there was TXLSFile for Biff8 format, there is for example OExport library. There is also a component from well known TMS Studio and maybe some more.
5) You can join some open-source project and try to enhance it for your needs, then again that depends upon how much the subset you need.
I know, many people succefulyl use OLE DB to access Excel data, but for me it always sounded as some perversino, because Excel files do not have any internal regular data arrangement at all, less so strictly-tabular RDBMS-like one.
I've really only ever found it possible to manipulate Excel via COM. I've tried alternatives, like ADO, but they always seem so full of archane bugs - or maybe it's just my ignorance.
COM is definitely slow in certain areas. I've used a combination of COM and (within the Excel file) VBA to achieve what I need to do.
Given that Excel is NOT going to go away BUT Microsoft cannot be relied upon not to betray its users by, for instance, doing away with VBA and COM support, it would be great if someone, somewhere (and I wish I had the skills) could create some proper support for Excel from Delphi.
I am doing a lot of similar tasks among some VBA scripts I am writing and would like to develop a library (a bunch of convenience functions using the typelib I'm working with) which I can call from all my various scripts. I am new to the VBA world and do not know how this is done and have had a surprisingly hard time trying to figure it out.
I think what I was looking for is an Add-In. Thanks everyone for your information.
Does this example help? It appears to also have a fix to a common issue when setting this up - You didn't mention which version of office - But 2003 is mentioned in that thread, so should be the fairly straight forward common case.
http://socko.wordpress.com/2008/06/01/vba-code-library/
Another option you have though it depends on the nature of your functions, is to create a COM object that you can call from your VBA scripts.
You can easily create a COM object using many languages including Delphi and VB (old style) it is also possible in .NET though a little more involved. You can then do your calculations in your COM object and even pass in the excel worksheet etc you wish to manipulate if required.
Depending on the nature of your functions this may or may not be useful.
You will need to use VB to do this. With Microsoft plug-ins to VB, you can manipulate Excel files without even opening them, much like you do now. The code will be very similar once you have the file open.
I would transfer all my code to VB and after its working like you have your VBA macros start making libraries out of the common stuff.
Lots of work, but if you really are doing a lot of this stuff, it will be great in the long run. (Job security too ;)
Check the comments here
http://www.dailydoseofexcel.com/archives/2004/10/15/code-libraries/
I would like to be able to link some data from a custom application to a cell in Excel.
What tech would you use to do that? I'm primarily a Unix-developer, and don't know win32 technologies in depth. But as far as I understand DDE would be the easiest, even though it is very old tech.
Being able to use it with other office suites such as OpenOffice would be a big bonus.
What does it mean "link data from a custom app to a cell in Excel"?
Do you want the Excel sheet to display data that is generated by some external app?
If that is the case there are a number of options.
The Excel data provider is one way to go. This works if you have lots of data you'd like to load. For just one cell, it may be overkill.
If the external data is accessible via a network interface (let's say, HTTP), then you can write some Excel macro code to consume it. You could use the ServerXmlHttp object to consume it, from within Excel. Some guidance on that is HERE.
Another way to do it is to expose the data via a custom COM object, a re-use construct that is very consumable by Excel. You'd have to write some code to do it, but it's not too complicated. You can write it in .NET, C++, Javascript, VBScript, PerlScript, ...
In .NET I would use the COM libraries for Excel. You can use Workbook, Worksheet and Range objects to address specific cells in specific worksheets and workbooks. These work well from .NET (especially VB.NET).
The COM interface is really easy. You start by recording a macro, and do what you intend to do. After that translate the generated code into the programming language of your choice.
All solutions I have seen here have the approach to push the data to excel.
Why not give the responsibility of pulling this data to Excel itself?
Excel does have the ability to add data through oleDB and ODBC. (at least from the version I know) I can only test that in Office2007, the only version I have on my machines.
All you have to do is add this option to the spreadsheet with the data tab.
Pretty simple. That way you also free yourself from the burden to maintain the code in your app to open Excel, run some code to push the code into the cells etc.
You could probably record a macro for this and run that when the excel sheet is opened.
Easiest way to link to a cell value is via the .net data providers in Visual Studio 2008. Here is a link to some of the more common methods. Link
It's going to be difficult to try and make this available to open office as the data providers aren't the same.
I'd recommend using Java/JVM and its Apache POI library.
It can read and write Excel files and it's pure cross-platform java.
It's pretty reliable in practice.
http://poi.apache.org/
Jonatan,
If the source application stores the data in a database, or a text file, it will be possible to use excels' build in data functions to retrieve it. Otherwise I would agree with Dayton on the integration with VS2008. You can use VS2005, however it will require you to install VSTO.
Regarding DDE - aside of being almost obsolete, there are problems while using different versions of Excel and different languages, which will require you to use different keywords for the same operation
Just to clarify: DDE works with open office. I am a Bloomberg user, and I opened an office 2003 spreadsheet in open office which contained bloomberg links to stock prices updated via DDE, and it works like a charm.
I have an old Excel 4 macro that I use to run monthly invoices. It is about 3000 lines and has many Excel 5 Dialog Box sheets (for dialog boxes). I would like to know what the easiest way would be to change it into VBA and if it is worth it. Also, if once I have converted it to VBA, how to create a standalone application out of it?
I have attempted this before and in the end you do need to rewrite it as Biri has said.
I did quite a bit of this work when our company was upgrading from Windows NT to Windows XP. I often found that it is easier not to look at the old code at all and start again from scratch. You can spend so much time trying to work out what the Excel 4 did especially around the "strange" dialog box notation. In the end if you know what the inputs are and the outputs then it often more time effective and cleaner to rewrite.
Whether to use VBA or not is in some ways another question but VBA is rather powerful and extensible so although I would rather use other tools like .NET in many circumstances it works well and is easy to deploy.
In terms of is it worth it? If you could say that you were never ever going to need to change your Excel 4 macro again then maybe not. But in Business there is always something that changes eg tax rates, especially end of year things. Given how hard it is to find somone to support Excel 4 and even find documentation on it I would say it is risky not to move to VBA but that is something to balance up.
(Disclaimer: I develop the Excel-DNA library)
Instead of moving the macro to VBA, which uses a COM automation object model that differs from the Excel macro language, rather move it to VB.NET (or C#) running with the Excel-DNA library.
Excel-DNA allows you to use the C API, which mirrors the macro language very closely. For every macro command, like your dialogs, there is a C API function that takes the same parameters. For example, the equivalent of DIALOG.BOX would be xlfDialogBox - there is some discussion and example in this thread: http://groups.google.com/group/exceldna/browse_thread/thread/53a8253269fdf0a5.
One big advantage of this move is that you can then gradually change parts of your code to use the COM automation interface - Excel-DNA allows you to mix and match the COM interfaces and C API.
AFAIK there is no possibility to somehow convert it. You have to basically rewrite in in VBA.
If you have converted to VBA, you cannot run as a standalone application. As VBA states Visual Basic for Application, it is living inside an application (Word, Excel, Scala, whatever).
You have to learn a standard language (not a macro-language) to create standalone applications. But you have to learn much more than the language itself. You have to learn different techniques, for example database handling instead of Excel sheet handling, printing instead of Excel printing, and so on. So basically you will lose a lot of function which is evident if you use Excel.
Here is a good artikel about this topic: http://msdn.microsoft.com/en-us/library/aa192490.aspx
You can download VB2008-Express for free at: http://www.microsoft.com/express/default.aspx