VBA to Use Outlook 365 (Web) vs local Outlook

NearImpossible

Registered User.
Local time
Yesterday, 18:36
Joined
Jul 12, 2019
Messages
225
I am using the following code to generate emails from my Access database using a locally installed version of Outlook and it works without issues, but what would I need to change to be able to use Outlook 365 Web?

Code:
Dim oOutlook As Object      'Outlook
Dim oEmailItem As Object    'Email

Set oOutlook = CreateObject("Outlook.application")
Set oEmailItem = oOutlook.CreateItem(olMailItem)
      With oEmailItem
           .SentOnBehalfOfName = "sender"
           .To = "recipient"
           .Subject = "Subject"
           .HTMLBody = "Text"
           .display
           '.Send
       End With

I've never dealt with email setups in VBA before as I'm pretty much self taught via dissecting code I find on the web and Q&A forums like this one.

Please advise

thank you
 
At first blush, I would say you change nothing at all in Access. What you would have to change is the program that is selected for your Windows default e-mail program. However, if you have both "local" and "could" versions installed at the same time, I think your change would have to occur in the CreateObject. Once the object is created, it should all be same/same.


This link suggests that you can control the selected version via VBA Page >>Tools>>References by chosing which library you reference. If so, then again, there should be no particular Access action to do differently.
 
I'm going to be more negative and assert that unless the program uses VBA that will make the requirement difficult if not impossible.
So, for example, I don't think its possible to send emails from Access using Windows Mail, Outlook 365 Web, Novell Groupwise etc

As an alternative why not send emails direct from Access using CDO? CDO EMail Tester - Mendip Data Systems. No need for any external email app.
 
I'm going to be more negative and assert that unless the program uses VBA that will make the requirement difficult if not impossible.
So, for example, I don't think its possible to send emails from Access using Windows Mail, Outlook 365 Web, Novell Groupwise etc

As an alternative why not send emails direct from Access using CDO? CDO EMail Tester - Mendip Data Systems. No need for any external email app.
Interesting, I'll have to mess with this and see if I can make it work as it appears to be a stand alone emailing tool

server settings will be static as corporate uses exchange, I am already capturing the username so I will just need to prompt them for a password,

Will work in some scenarios where the user is driving the reason for the email, but not all as I am also trying to setup my database to automatically send email reminders based on a few different settings.
 
Colin, did I miss something? The OP asked about "local" Outlook switching to "cloud" Outlook, not GMail or something else. I don't see that anything would change except the version of the .DLL files that get referenced. Outlook is supposed to be Outlook regardless of version, as long as you use the right references. I hesitate to say you are outright wrong, but I don't see the source of the negativity in your reply with regard to the question as it was asked.
 
Hi Doc
I hesitate to say you are outright wrong ;) ...but...
As you know, there are many different versions of Outlook and, despite similarities in name, they are not all the same 'beast'.
My understanding is that none can be handled using VBA from e.g. Access except for desktop version
I may be wrong about that in which case someone will provide info on how it is done.

In any case, CDO provides a different solution which may be simpler for the OP

I mentioned other email programs as further examples that may be similar in this respect. Well over a decade ago, the network manager at my workplace, insisted on blocking Outlook in favour of Novell Groupwise. As a result, I spent a long time trying to automate Novell Groupwise from Access before eventually having to admit defeat. It was mainly due to that that I started using CDO to send email.
 
Don't disagree that CDO might be simpler. I wasn't answering that question and my answer WAS based on some web searches. That's why I was confused by your response.
 
It would be very useful to be able to automate the Web version of Outlook. My understanding is that you can't but perhaps I'm wrong.
If your research indicates otherwise, please do supply code that will allow this to be done. I would be glad to see it.
 
Maybe I am confused on nomenclature. I will return to my sources to see if THEY were specific enough. As you point out, there is a profusion of names in the Microsoft community. And you were very gentle in your disagreement, so don't worry that I might be offended. After all, I put up with Adam's rambling for a long time, didn't I?
 
Being as you mentioned YKW, you may be interested to know he has recently been permanently banned from UA...for the usual reasons.
 
Why am I not surprised. But he still has one viable account here. He came back briefly but either is merely lurking or has moved on to some other forum to harvest his particular brand of chaos.
 
Maybe I am confused on nomenclature.

It could be that the OP is using the browser-based version of Outlook, which I've heard called OWA. I don't see that being automated, at least not with the same code.
 
OK, the articles I found were using Outlook 365 but NOT the OWA version. My response was because I didn't realize the dichotomy existed. Sorry to spin folks up. My comment stands for the "cloud" Outlook that ISN'T the OWA version, but it does not apply to OWA.
 
OLE automation only works on local apps that support it. It can never work against cloud apps although I do recall using it with Groupwise. Colin's suggestion is probably the only answer.
 
@Pat Hartman
Well done if you got Access to send emails through Novell Groupwise. As mentioned earlier, I tried hard but failed. Mind you, the network manager went out of her way to make things difficult in this regard so it may be she had locked the system down more than necessary

@The_Doc_Man
Are you absolutely sure that automation is possible for the "cloud" Outlook that ISN'T the OWA version.
We both agree it doesn't apply to OWA.
 
@isladogs, it was in the late 90's and I remember fighting with it but the administrator was trying to help not hinder the process:)
 
I'll have to find the article again, but the implication is that the cloud version still runs on your machine, having been downloaded as part of your cloud contract. The telling point is whether Outlook "cloud" still requires your Access to have a reference to the Outlook library file.
 
I wonder if there is confusion with the word "cloud", between Outlook and Exchange. There is "hosted Exchange" where your email is routed through cloud servers instead of an on premise Exchange Server. I have users in one city where we use hosted Exchange. Users have a version of Outlook installed on their PC, and it connects to Microsoft.com to get email. Users in another city have an on premise Exchange server. They also have a version of Outlook installed on their PC, but it points to the local IP address of the Exchange server. In either case the Outlook is automate-able because it's a program installed on the computer.

I could get on any PC in the world and fire up a browser and connect with OWA to either system, provided I know the IP address. That would be "cloud" Outlook, which to my knowledge is not automate-able because it isn't a program installed on the computer, it's just a website.

I guess what I'm wondering is if by "cloud" some are actually referring to Exchange rather than Outlook.
 
As I understand it, there is some vestige of something installed on your local machine even if you are using SaaS Office. That is because Office is not a client-server system. When you are running Word, the code runs on your local system but there may be something sort of like the situation that used to occur with Office "local" installations that said you would run some features off the installation disk rather than having them resident on your local drive. You had THREE options for features: Not enabled, disk-enabled, and fully resident. The path of least resistance to SaaS is to take that middle option but make it network-enabled rather than disk-enabled.

In that case, you still are running code on your local machine, it is only a matter of how it got into memory. As I understand it, Office 365 was really just the SaaS version of "regular" Office 2019 but you paid a yearly fee for SaaS vs. a larger one-time hit for the "regular" version.
 

Users who are viewing this thread

Back
Top Bottom