I am trying to send e-mail from MS Access using VBA but cannot use the sendobject function as this doesn't support external file attachment.
Does anyone know how I can do this?
Thanks
One can use MAPISession control in VB 6.0, so I suppose it will be available in VBA too.
Using the MAPI Controls
Another way is to use Outlook object model, but it will require MS Outlook to be installed. However most users that have Access, usually have Outlook on their desktops too. See How to automate Outlook by using Visual Basic
And yet another one decision - you can use .NET (VB.NET for exmaple) to write a very small component that will use System.Net.Mail to compose and send SmtpMail. For you as VBA developer it will not be very hard. You can write one class with a single function SendEmail.
Then you can expose this class to COM, see Exposing .NET Framework Components to COM
Then you will have an ActiveX DLL that you can call from your VBA project (using CreateObject("") and so on)
If you are going to use the CDO solution (http://www.paulsadowski.com/WSH/cdo.htm) then you should be aware that as of Office 2007 CDO is not bundled with Outlook anymore. If you are going to use a CDO solution you will need to download the CDO library here and make sure that said library is also installed on any machine you plan on deploying your solution to. Another alternative would be Outlook Redemption. But either will work fine. And both will require deployment.
For an omnibus answer to this question (emailing from Access), see Tony Toews's Access EMail FAQ. Tony recommends doing it directly via Winsock as this avoids any need to worry about versions of components like CDO or distributing DLLs or installing ActiveX controls. The downside, as Tony admits, is that it's substantially more code-intensive.
CDO seems to work best. You can Google CDO.Message or check out this link: http://www.paulsadowski.com/WSH/cdo.htm
Related
I'm the new maintainer of an application that was previously done by a contractor. The application was developed using VBA inside an Access project. It consists completely of forms (one of which is opened using autoexec macro) and stuff like click handlers. I don't see any use it makes of Access functionality except for accessing the tables using ODBC table linking done in Access.
These are the reasons I would like to convert this application to a standalone application if possible:
There is no version control at all, just multiple copies of the same project with an incrementing number appended to the filename
The VBA IDE is super annoying
I think the code could then be migrated to more modern languages like C# or VB.net making it more maintainable
Is there any way to convert this to a separate Windows application (I guess using WinForms as that seems to be the same as the forms in VBA) that can be maintained in Visual Studio?
Access for 20 years has supported the standard ‘Microsoft source code control interface. This is outlined in this post:
Version control for VBA file
And this one here:
How to implement version control in Access 2003?
There really little or no reason why Access + VBA, or vb.net can’t be used with source code control. However the SCC add-in that was part of Access was depreciated in 2013. So for versions after 2010, then you can use a script to export the objects. This works quite well – I am using GitHub with Access. So you need a script to export objects now that the SCC add-in is not included in versions beyond 2010 and it works rather well. Access can view each object as "logical" separate. So having all parts in a folder, a zip file, or the Access continuer is moot - don't fall for the physical vs logical concept here that so many people fail to grasp.
•The VBA IDE is super annoying
Hum, never really had much issue with it. I spend good parts of my day using VS2013 and vb.net, but for the most part the VBA IDE is fine for most Access applications. Can you give an example of what feature or something that you find bad with the VBA IDE?
•I think the code could then be migrated to more modern languages like C# or VB.net making it more maintainable
I can’t see why code written in c++, or Pascal or VBA is going to be more or less maintainable? You have to give an example of what you mean here? Maintainable code is maintainable if it is COBOL, Pascal, or VBA.
I guess using WinForms as that seems to be the same as the forms in VBA
No, Access does not use winforms.
Access as a developer tool not really different then say using FoxPro, or say Delphi. Such code and systems can be re-written like any other software development system would require that I am aware of say in the last 30 years of desktop development.
As a general rule, something written in say Delphi, or Access + VBA is not going to by some act of magic is going to be converted to WinForms and .net. That goes for just about any IDE and system I am aware of.
So software in the general computer industry never worked this way in the past, and thus Access is really much the same as most everything else in this regards.
I have a database in ms access 2007 with forms. I need to create a stand alone exe file from access. Is it possible? If so, how?
You can't save it as .exe, but you could use the Access Runtime to allow users without Access to use your Application.
If I can just add my two cents worth...
You DO have to distribute the Access runtimes with your application. I heard recently on Stackoverflow on a questions that Microsoft runtimes for access are now freely downloadable.
Here are a couple of links...
http://www.granite.ab.ca/access/developeredition2007faq.htm
http://blogs.msdn.com/clintcovington/archive/2007/01/30/the-runtime-and-developer-extensions-will-be-free.aspx
You can either distribute these runtimes with your application or you can have your customer download them.
EDIT - THE BELOW IS PROVEN FALSE. YOU DO NOT HAVE TO PURCHASE A LICENSE TO DISTRIBUTE THE RUNTIMES. Of course, they are distributed under a license but the license is free. I leave the comment below for its historical interest.
I think but am not sure that to distribute the access runtimes with your application you will have to have a license. I know that you used to get this license with an MSDN subscription and with Visual Studio Tools for Office.
END FALSEHOOD
Once you have the Access Runtimes, you can create BULLETPROOF runtime installations of Access apps using preconfigured installation scripts from SageKey.com.
Office developer tools comes with some deployment options but they are not bulletproof and I would NEVER distribute a commercial application using those...they just don't work. But the sagekey scripts absolutely ROCK. They work incredibly well.
All this presumes you want to widely distribute your app. If not (for example...you want to just deploy to your customers and you will have complete control over that) then you can use the download from Microsoft option mentioned above.
One last thing. Runtime access apps have to be VERY robust. You have to do error handling and automatic table linking very well among other things or you will spend all the time on the phone with your customers rather than selling/distributing software.
Hope this helps.
Seth
If you have the Developer version of MS Access, you can create an '.mde' file, which operates just like an .exe file as far as your user is concerned. Essentially, creating an .mde wraps a version of the MS Access run-time along with your database.
As long as you have done a decent job with your form design, the user really can't tell the difference between your .mde file and a .exe.
I haven't used the Developer version in a number of years, but if I recall, it is quite expensive. EDIT (It appears to be free these days).
Here is a link to a good FAQ on the topic. Much more up-to-date than my recollections from the past.
As far as bullet proof runtimes yes Sagekey is an answer. However another alternative is Albert Kallal's Inno script which checks to see if a version of Access is installed. If not it tells you to install a runtime version of Access. If installed then it continues to install your FE MDE and other assorted files.
http://groups.google.com/group/microsoft.public.access/msg/10e3fc9234660872?hl=en
Sample inno script which "wraps" the package wizard install into a single .exe
http://groups.google.com/group/comp.databases.ms-access/msg/4aa1b33a191bf1f8?hl=en
Deploying updates to your software in a Runtime environment for Access 2007
http://www.members.shaw.ca/AlbertKallal/RunTime/InstallExample.htm
The only scenario which it wouldn't handle well would be if the user does install Access or a different Access runtime on their system later. However if you ship your product in Access 2000 format the problems are minimized.
no it's not possible.
I don't believe it is possible. Sorry to say. You need the Access to launch and display the form.
I'm using Crystal Reports XI Viewer Active control in an Access 2007 (but 2003 format) form. I'm using SQL Server 2008 as the backend. The viewer displays reports fine, but there are no toolbar icons. Buttons and tooltips work as expected, just no images.
Searching for this, I've seen countless references to this problem using the WebForms viewer, but not the ActiveX control.
I thought maybe it was a missing reference, so I added every Crystal version 11 DLL the References dialog offered. I suspect it may yet be another, but don't know what else to look for.
Has anyone else come across this? Any ideas?
(Please don't recommend using Access's built-in reporting instead. Business requirements dictate Crystal so my hands are tied.)
Adding all the DLLs is not going to do anything that dropping the ActiveX control on a form will not already have done. That is, using an ActiveX control automatically creates the appropriate reference in Access.
I recommend against utilizing any ActiveX controls (except the ones that are built in) in any Access app because there are so many installation problems they can cause.
Not all ActiveX controls are compatible with Access, so you need to check with your vendor to see if they think it is. If not, then you're probably out of luck. It's unlikely there are many Access programmers out there who've attempted to use a Crystal Reports ActiveX control in Access itself, as there's not much need for it in the vast majority of Access apps.
Is there some other interface that you can use other than an ActiveX control? What does it do? Display the report in a form?
Problem fixed itself after closing and re-opening Access.
I have a huge MS Access document with built-in VBA codebase. Is it possible to track the file (as I am developing it) with a (mercurial) version control system? Can I extract code and track that? Or is it just the-binary-file-path? Thanks.
It's possible with MS Access to export most of the code through scripts. I posted some here a while ago:
How do you use version control with Access development?
It's possible to version-control binary files, but it would be a little cleaner (IMO) to have the code separate. If it works for you though, then by all means do what you do.
There is a nice tool here https://github.com/hilkoc/vbaDeveloper .
It allows you to easily export and import all your vba code and can do this automatically as soon as you click 'save'.
The export files are all plain text which you can then put in version control in the usual way.
Access all the way up to 2010 has supported source code control, and that includes support for team foundation server. The fact that you place all files in ONE zip file, one folder on a hard drive, or one container called an accDB is a MOOT point. As long as EACH individual object can be viewed as a SEPARATE object, then why do you care if one is using a zip file, or an accDB file? This is a “logical” view vs a physical view issue.
The simple matter is EACH OBJECT IN ACCESS CAN BE EXPORTED AS A TEXT OBJECT. Thus Access has supported source control integrate using this ability with the standard Microsoft SCC interface since Access 97 (that is 17+ years!!).
When you use SCC such as Visual Source safe or Team Foundation server then the BUILT IN UI in Access supports display the objects status in question. You have resolution down to the form, report, sql query and code module level. So multiple developers can all work on the application at the same time. They only need check out the forms, reports quires etc. they are working on. Each developer thus has their own local build.
If using Visual Source Safe, then you see this in the ribbon:
If you using team foundation server, then you see this:
And for objects checked out, you see this:
And when you open, or even right click on an object, you see these additional options:
Of course given that “few” use this feature or even know what it is (and the posts on SO confirm this lack of knowledge), then it is LITTLE surprise that the feature was dropped in Access 2013 after all these years!. However some 3rd party add-ins claim to restore this ability. So the ability to export objects in 2013 as individual text files STILL remains in place.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Version control for VBA file
Does any kind of version control exist?
If no, is there any good solution for collective development of MS Access 2007 database with VBA ?
Microsoft have produced a Source Code Control add-in for Access 2010:
Source Code Control add-in allows
integration with Microsoft Visual
SourceSafe or other source code
control systems to allow
check-in/check-out of queries, forms,
reports, macros, modules, and data.
You can also see the differences that
have been made to your checked out
objects.
The only one integrated VC solution for Access is Microsoft Visual Source Safe however it's poor designed and even Microsoft internally avoid from using it ;). Some people call it "Source Destruction System", but I personally know success cases with using it. Generally, it could be a good solution for small and medium projects due to its limitations.
Here is a very critical article about VSS:
http://www.highprogrammer.com/alan/windev/sourcesafe.html
The other option is to design your own code to export VBA solution using Application.SaveAsText() - it's partially undocumented feature of Access API.
I work with an Access application and Team Foundation Server Source Control. You need to switch the source control provider Access expects; I used this tool, Sourcecode Control Switcher, to do so when we moved from VSS to TFS. Once you've switched, you can setup the source control settings in Access and build a source-control-connected .mdb from TFS. It works nicely.