You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
Aleksandar Jakšić, who is one of the testers on our team, has written an article that shows you how you can use the Access Database Engine from native applications written in C/C++.
The article shows you how to to the Access Database Engine using C or C++, but has a great discussion of the data stack used by Access and some of the different components of the engine. He also breaks down the different methods for accessing data using native technologies such as DAO, ADO, OLE DB, and ODBC. The article provides great insight about the engine and the mechanisms that are used to connect to it, regardless of whether you are writing native code.
The article is available on MSDN:
Developing Access 2007 Solutions with Native C or C++ http://msdn.microsoft.com/en-us/library/cc811599.aspx
Comments: (10) Collapse
I don't program in C/C++/C#.
What I desperately miss in MSDN Library is VB/VBA examples for Windows API. Windows API documentation should be delivered with each Microsoft developer's tool, ie. programming language, VBA-enabled applications, etc., eg. MS Access. ;-)
Off-topic: Blog-server's response is very slow since yesterday morning.
Off-topic: Bug in Developer Extensions? Developer Extensions PDW doesn't add referenced files (OCXs) to MSI!
Off-topic: Bug in Developer Extensions? ctnd. There may be a problem with other types of files (DLLs, EXEs, ...) and dependency files! What a mess!
This is superb. Every one of my clients has had their IT department put the fear of God in them if the use Access. Simply being able to show them this article will give them the confidence boost they need. All they really want to know is that they can convert an existing Access database to an industrial strength DB if and when the need arises. I have two questions:
1) I use automation to produce Excel files, mailmerges through Word, and emails in Outlook directly from the Access forms. Is this possible using C++ ? or is there some kind of workaround which doesn't involve the client opening another application 2) How does the C++ approach handle reporting ? Thanks
Ken the Access Database Engine merely reads and writes to accdb files. ACE/JET was always the weak point in Access. Use DB2 Viper 9.5 or SQLS2000+ if you want industrial strength databases. Reporting is part of Access not the engine.
Off-topic: WARNING!!! There are some indications that some (event) procedures don't fire in Access 2007. We're just testing our application in A2007 which we started to develop in A2002. Some forms didn't pass the tests in 2007 so that I made debug printouts in the same form. Access 2002
--------------
toto hledam
toto taky hledam
frmPZ_Denik.RecordSourceselect * from qryPZ_denik where ((DD=TRUE) And (ID_FOkn Is Not Null))
Me.Parent!frmPZ_Denik.Form.RecordSource=select * from qryPZ_denik where ((DD=TRUE) And (ID_FOkn Is Not Null))
=============================================================================
Access 2007
frmPZ_Denik.RecordSource
Me.Parent!frmPZ_Denik.Form.RecordSource=
Me.Parent!frmPZ_Denik.Form.RecordSource= The form that is performing OK in A2002 doesn't work in A2007. It seems that Access 2007 is not compatible with Access 2002.
Windows XP CZ SP3
Access 2002 CZ SP3
Access 2007 CZ SP1 Anyone else have similar indications? Please, let us know as soon as possible. I hope I'm doing something wrong... Thank you very much for your time in advance.
Thanks for the info Craig I should have been more specific with my question 99% of the database front ends I create interface with Word, Excel and Outlook through automation so the client only has to use one "program" - this is a big selling point for me using access I am interested in how Aleksandar Jakšić by using C++ resolves the issues of mailmerges, Excel exports/imports and automated emails without switching to multiple applications and all the effort that involves I have a number of databases which use back ends like SQL or Oracle but I am interested in the froont end approach here Thanks Ken I
Ken, first of all, thank you for your feedback. When you say "without switching to multiple applications" do you by that mean that you want to accomplish these front-end tasks without booting the application(s) themselves? Depending on the particular Office application, all or most of the actions that you can perform manually through the user interface can also be performed programmatically. Office app exposes its own functionality through an object model (OM). Native C++ techniques explained in this article can also be used for other Office applications. C/C++ is extremely powerful language; large chunks of Windows and Office themselves are written with it, so to answer to your question, yes, it should be possible to use the automated approach. Visual C/C++ supports at least two different ways for the interaction with Office applications: Legacy and automation. Legacy approach is well documented in MS Knowledge Base. Basically, it uses MFC wrapper classes for accessing underlying Office libraries which programmatically expose their OM functionality. The automation approach is a new technique which utilizes the “import” directive by creating the object pointers directly from underlying Office library, and with these pointers you have direct access to core functionality. Automation uses COM calls such as CoCreateInstance(), and interfaces such as IDispatch, etc. DAO Direct method described in the article is good example of this approach. Chapter 24 of David Kruglinski's "Inside Visual C++" (ISBN:1-57231-565- 2) supplies a general overview of Office automation as well as some great examples. Other good books that you might want to check out are "Inside Ole - Second Edition" by Kraig Brockschmidt, ISBN 1-55615-843-2, "Inside COM" by Dale Rogerson - ISBN 1-57231-349-8, and "Automation Programmer's Reference," ISBN 1-57231-584-9. Hope this helps.
Thanks Aleksander That's what I was hoping for I'd use the new automation approach as that's how I do it in Access - the clients love it because they can write letters, emails and Excel files from various screens as and when they need to without manually loading Word etc An example is an Insurance company getting a policy cancellation request - as soon as they enter the cancellation date 1) a cancellation confirmation letter to the polcy holder is produced 2) an automated email is created to inform the risk department that they are off risk 3) an automated email informs the claims department they should ignore claims lodged after the cancellation date 4) the sales person involved receives a cancellation email as this will probably affect their commission 5) if an independant Insurance Adviser is involved they receive a cancellation confirmation letter I'll be off to the shops on Monday to check out the books you mentioned Thanks again Ken
Comments: (loading) Collapse