Outlook has a neat conflict resolution system to solve the problem that sometimes your mails and the server mails are different. But sometimes it fails, and asks the user to solve it instead.
It would be troublesome to task a common user with that kind of job - Even more when a simple script or VSTO addin could do the job, without the need of user interaction.
But as far as I can tell by the official Microsoft documentation, there's no way to really do it, either by VBA, .NET or VBScript, as the framework lacks a "Mark this object as winner" method or anything similar.
There's some kind of way to do it anyway, even without officially supported methods and calls?
It would be better if I could implement it using a VB.NET VSTO Outlook Add-in, but any other way would be acceptable.
For reference, the conflict would be resolved in the following way: The newer one always wins, and the change made by the local user running the Add-in always wins if the first one fails.
The conflicts are being generated by a Addin that categorizes the emails based on a Access database - it runs just fine, but on synchronization with the server, some users get sync issues - others do not.
As a lowly summer intern, I have no way to change Exchange configuration or anything like that.
One of my solutions was this piece:
Public Sub TryToResolveConflict()
If MailItem.IsConflict Or MailItem.Conflicts.Count > 0 Then
If MailItem.AutoResolvedWinner = False Then
MailItem.Display()
MailItem.Close(OlInspectorClose.olSave)
End If
End If
End Sub
It just opens the mailitem and closes it again, saving it, if any conflicts are detected and it's not the AutoResolvedWinner.
As any other poor constructed solution based on ignorance, it does nothing at all.
Related
Recently I have created an Addin for my outlook 2013 in VB.net. I usually do a lot of modifications on this application especially in the beginning. These modification automatically download when a user starts its outlook as soon I publish the project.
The question I have, and which I cant seem to figure out how to do it is:
Is it possible to show the user some kind of custom made UPDATE pop-up text when outlook automatically updates the addin?
So a user starts its outlook, then the outlook usually executes the updates pretty fast and then I want them to show some kind of message which contains the updates being done.
I have no clue if this is possible though and I cant seem to find an option for it in the publish tab of visual studio. Can this be done with code, and if so, how?
ClickOnce doesn't provide anything for that. See Deploying an Office Solution by Using ClickOnce for more information.
In the new version of the software which you are going to publish you may add a message box. It can be shown for the first run only. For example, add a windows registry key which indicates that the add-in (new version) is run for the first time. Reading the value at runtime will help you to decide whether such message box is required or not.
The problem I'm running into is already described at Getting/Creating an Outlook Application in Windows 7 but I had a very hard time identifying the source of the problem because I happen to be maintaining an old VB6 application at the moment, and the errors that are reported from VB6 applications are not mentioned in that article. Furthermore, I'm looking for better solutions.
The problem is that CreateObject("Outlook.Application") and GetObject(,"Outlook.Application") are failing with Error 429 - ActiveX component can't create object, particularly on Windows 7. The source of the problem turns out to be that if Outlook is already running under a normal user account and an application is running as an administrator (not unheard of for old 32-bit applications running on Windows 7) wants to access Outlook, the request for an Outlook COM interface hangs for 30 seconds and then fails. It seems to be related to the fact that the requested instance of Outlook and the already-running instance of Outlook are using different user accounts or privileges.
It would be nice, first of all, if a better error could be reported, and if it could be reported more quickly. Usually the application hangs for 30 seconds before reporting the error. So the first question is, is there any way to detect this condition without waiting 30 seconds?
Next, is there any way to work around this error so we don't have to care that Outlook might already be running under different credentials when we want to access the Outlook API? One thought is turning off UAC so that the old 32-bit application is less likely to need to be running as administrator. Is there a better solution?
I assume you 've alredy resolved this, but just in case, i had the same proble and the solution for me was to terminate the procces outlook.exe with an API and then do "CreateObject"
you can do what is next:
if err.number = 429 then
terminateprocces ("outlook.exe") 'u can find function code on intenet
resume
end if
I solved this issue by installing the VB6 application locally instead of on a network drive.
Unchecking Run As administrator in the shortcut properties may have helped.
Just a little background: I am using Access 2010 to create forms and VBA code in an Access 2003 format database. For some reason, Access 2007 format databases always corrupt on me when I make changes and save them with a particular group of objects, but that's for another discussion.
When writing VBA code in this Access 2003 database, any time my code breaks (via breakpoint or an unhandled error) and I make a correction, Access tells me that it can't save back to the database because another user has it open. However, I am the only user working on the database; this is a local copy of the database and it's sitting on my desktop.
The LDB file can't be deleted because Access is using it. When I first load the database, I see my machine name and "Admin" when opening the LDB in a text or hex editor. After a break, I see that plus a duplicate entry, but this time around "admin" has a lower-case "A."
Closing the database and reopening it fixes the problem but makes it needlessly cumbersome to debug my code. Anyone else encounter this issue and/or have a fix for it?
It might be helpful to know what your code is doing when this happens. Certainly that's not normal behavior. For instance, are you opening another database with New Access.Application? Are you using ADO or DAO to access records in the database with a connection string?
There are no external connections to the database at all.
It may not matter if there are external connections to the database if you are using a connection string to connect to the open database; not sure but that may be seen as an external connection... you may want to use CurrentDB for DAO, or CurrentProject.Connection as your ActiveConnection for any ADO queries.
I am assuming that this problem persists through reboots; but for the sake of argument, try closing out Access and going to the task manager to make sure you have no other instances of MSAccess.exe running. You might even try closing all Office products and/or making sure that Access is the only Office product running. I have seen some weird conflicts between Microsoft Communicator and Outlook; so it's not entirely out of the question for Access to have issues with another MS product.
You may also want to check the size of the database to make sure it's not exceeded 2GB. That causes the infamous "Invalid parameter" error; perhaps it might be causing this as well.
With no other details about how your program works, we may only be able to offer generic advice like this.
I have discovered a way to cause the problem discussed above (and thereby to correct it). Turns out if you create a database object and set it to the current database, you get this problem.
That is,
dim cdb as database
set cdb = currentdb
From this point on, you're cooked.
Instead, figure a way around this by possibly using currentdb directly or not using it at all.
This worked for me.
In your VBA Try checking that all your open Connections to the database are closed. Until the connection is open the LDB fill will be there.
Same symptom of not being able to save form or code mods after application had started. I found a workaround today! In the startup of my first form of the app, I had issued a "DAO.DBEngine.SetOption dbMaxLocksPerFile, 20000". Commenting this statement removed the problem. I did no further testing, but FYI, the DBEngine call was before any reference or attempt to use CurrentDB(). Also the current default on my Access 16 install is 9,500.
I thought I might answer here, since I stumbled upon this question while having a similar issue. Essentially, it boiled down to this: I could either edit forms, VBA, etc. or edit information in the local database (which I'm using as a cache) with currentDB. I also have a backend database, but the locking was clearly on the frontend database.
The solution ended up being weird, but stupidly simple. When the frontend starts up, I have it immediately create a connection to the backend using OpenRecordset (and similarly to you, that backend was still on my own computer for testing purposes). I tried temporarily disabling that code, and suddenly it wasn't an issue anymore. And it turns out, once I call currentDB, I can then call OpenRecordset to open the connection to the backend, and suddenly it isn't a problem anymore.
Tl;Dr: if you're calling OpenRecordset somewhere in your code to connect to a backend, be sure to call something like set db = currentDB beforehand, then everything works. (That is, probably until I publish this answer and Access then decides it doesn't want to anymore).
Why this fixed it is beyond me, someone with more knowledge can maybe answer that.
The solution:
options > current database > click enable -track name auto correct info
I have a form that has a list box and several buttons that run sqk statements for the list box.
sub on_onClick()
' error checking
me.listbox.rowsource = "SELECT tblMain.First, tblMain.last FROM tblMain ORDER BY tblMain.Last;"
so this kinda thing is what I use for the list box. it works fine for me in the .mdb, and after i have converted the database, split it, made the .mde I go into the mde and it works fine for me still. This is placed on a shared drive
HOWEVER, anyone else that tries to use this, none of the buttons are having an effect. Can't tell if they are not working, or the VBA is not returning any results for them. It works for me, but it is not working for them. So...this is for my local LAN team, I think they all have full control permissions??? The button clicks that get them to that form are working fine also.
please help!
A couple of things come to mind:
It is not clear from your question whether the mde file itself is on a shared drive or whether the back-end database is on the shared drive and each user has a copy of the mde file on their PC. If the users are using the same mde file on the network share then I would strongly suggest not taking this approach. (It probably isn't the cause of the issue, but it will get you into trouble down the road.) Give each user a copy of the mde (front end) and have the application point to the back-end database on the network share.
Make sure that the mde has the ability to relink the tables to the back-end mdb file.If you search SO you'll probably find examples of how to do this in code.
I suspect you may be running into an issue where the mde file is not able to find the back-end tables. In this case you won't receive an error message in your VBA code when you're setting the listbox's rowsource and it will appear as though nothing is happening.
Do they have Macro security disabled? By default, MAcro security is enabled in Access and none of your VBA code will run. To disable: open Access, Tools -> Macro -> Security and set to low.
I think it is generally best to use self-certified projects or a secure location rather than change security levels.
Some information on macro security:
Self Certify projects
General information on security principals for Office code and macro security
Trusted location defaults for Office 2003
Macro security in Office 2003
My Application (Vb.net, Access 2003/2007) is to scan Access Database files for activex controls and to generate report accordingly.
Problem:
Getting an error like:
"Insufficient memory to continue the execution of the program."
The above error occurs while scanning for older version of Access files like prior to office 2000.
And the line of code where I get this is as follows:
Dim oForm As Access.Form
Dim oAccess as Access.Application
oForm = oAccess.Forms(objForms.Name)
But it opens the file and form as well.
Need Help:
Whether it is possible to read the file (Access Forms and Reports) or not?
Please provide me reference or any solution.
You appear to doing COM automation of Access to open the forms and then cycle through their controls looking for certain properties.
Another solution would also involve automating Access, but it wouldn't require actually opening the form, and that's the undocumented Application.SaveAsText command. You'd do something like this:
Application.Saveastext acForm, "dlgWebBrowser", _
"C:\Output\dlgWebBrowser.txt"
You would then have to figure out how ActiveX controls are described in that file. If that file looks like the code for a VB form, that's because that's precisely what it is.
The example above had an IE web browser control on it, and after a dump of OLE data, it had this in it:
OLEClass ="Microsoft Web Browser"
Class ="Shell.Explorer.2"
GUID = Begin
0x54c1ea41936d2046b9dc5b29905976e3
End
I would expect that all ActiveX controls will have an OLEClass, but I non-native avoid ActiveX controls on principle because of the problems they can cause if not properly installed when you try to run the app.
In fact, that could be the source of the problem -- if you open the Access form on a machine that doesn't have the relevant ActiveX control registered, it's going to fail, and the form won't open.
My bet is that Application.SaveAsText is going to sidestep that problem entirely, since the form doesn't have to be opened.
I've seen behaviour very similar to this before. Access 97 files will sometimes report an 'out of memory' error if you try to open them on a computer with more than (I think) 1Gb of RAM. The error doesn't always manifest itself immediately - sometimes the project can appear to run normally but crash when you try to open a particularly large object.
In the case where we did run into this the users were running an old Access 97 database on new XP machines they'd been upgraded to with modern amounts of RAM. Tech support for the company tried everything they could think of - including complete office reinstalls, applying all patches etc. but eventually had to resort to removing RAM from the computers - whereupon the errors went away and everything was rock solid again. I am uncertain as to the exact cause, but it will be connected with memory management in the Access 97 file format (I believe the error is on MSDN somewhere but I wasn't directly involved with Tech support hunting the solution down - I'd just written the application many years before)
I'd suggest you're only way out is to use a special, low memory, PC to run the application.