Assigning OutLook Tasks from Access (1 Viewer)

Hello again,
I am using Access/Office 2010 on a Windows 7 platform.

What I am trying to do sounds simple: I want to assign an Outlook Task to the individual selected in a form's combo box.

Here is my code that I took from an MSDN site:

Sub AssignedTech_AfterUpdate()
Dim myOlApp As New Outlook.Application
Dim myItem As Outlook.TaskItem
Dim myDelegate As Outlook.Recipient
Set MyItem = myOlApp.CreateItem(olTaskItem)
MyItem.Assign
Set myDelegate = MyItem.Recipients.Add("someone@domain.com")myDelegate.Resolve
If myDelegate.Resolved Then
myItem.Subject = "Prepare Agenda For Meeting"
myItem.DueDate = Now + 30
myItem.Display
myItem.Send
End If
End Sub

I do have the Microsoft Outlook 14.0 Object Library referenced and I got a clean compile prior to running the code.

When I select the intended Recipients name, I get a "Run-Time Error "287" Application-Defined or Object-Defined Error"

When I debug the code, the portion in red is the culprit.

I had posted this with a different title last week; one of the Heavy-Hitters on this forum weighed in a little but didn't really have any words of wisdom (very rare occurrence for this member!)…

However &”, “&PauseForEffect() - he did offer a suggestion that has caused my confusion factor to increase by .7%

I added the line "On Error Resume Next" just to see what would happen.

Everything works as it should; An Outlook Task displays with all the elements populated EXCEPT the “To”(Recipients)
So with that, I conclude that
- The code is correct
- All required references are loaded
- It MUST be local Access or Outlook settings that will not allow me to load a Recipient

One other thing to note is that I took this code home and ran it on my platforms at home. And although I cannot completely duplicate the Access version and OS (Access 2016/Win7 , Access 2010/Win10), both systems run this code with no hiccups.

Can anyone offer some insight/advice on this?

I've not tried outlook appointments from Access, however I have played with email quite a lot, one thing I have been caught out on is permissions. The Outlook account being used must have permission to carry out the action on the target account.
So you may well be able to insert an appointment in your own calendar but not someone else's ? It's only a thought, but might explain why most of it works, but not the last important little bit.

Thanks for weighing in here Minty,

Just to be clear, it is Tasks I am working with and not Appointments. That being said, I posted this exact post on Bytes and one of the better contributors on that site offered up his code for Appointments.

On a whim, I cut and pasted his code in my Form and it ran without a hitch. All the invitees I listed populated perfectly. So, peeling the onion a little further, I commented out the .Display line and inserted a .Send

I got the same error message but with a different Run-Time code. I am certain it is some sort of Security setting (did I mention it was on a US Gov machine?) that even IF our IT department knew how to change it, I sincerely doubt they would.

Not that big a deal, what it does at this point does work and in some ways may be a better option so the sender can edit the Task as needed before sending it on.

I just HATE work-arounds and loose ends.

I'm going to go out on a limb here and suggest that you are looking at this from the wrong end of the problem. As a test for S&G, ask one of the potential recipients to allow you (as the sender) to work on his .PST file. YOU can't do it easily, but your potential targets CAN easily define a proxy person with permissions to do stuff on their behalf. I think they can limit the nature of that permission.

This is based on the idea that most systems are on newer standards but the standards are based on the old "Orange Book" level called "C2" - which includes the concept of "User Discretionary Access." In practice, this means that the user can allow what you can't force.

Well Doc,

I'm flattered you think I know how th hack a .pst file! Fortunately, Google can make hackers out of no-skill office automatons.

Once I get back to work, I will give this a shot and report. Good idea, I might add...

I'm pretty sure this is a Domain / Exchange setting where by you don't have the authority/privilege/correct number of cookies in the jar/right coloured socks on/etc. issue.

As you have surmised I doubt you'll ever find out what without someone else having had the issue and beaten it into submission.

Mamma always told me that not matching my socks properly would come back to haunt me one day.

I shoulda listened....

Update:

Well Doc, for S&G I figured out how to establish myself as a delegate for one of the intended recipients (that is a funny story all by itself!).

Same result. I have determined that my app is just going to have to get along in this world in the absence of it.

I like the way you think though, it would have never occurred to me to work backwards like that...

One other question, and it may be that it is just a typo, but...

Set myDelegate = MyItem.Recipients.Add("someone@domain.com")myDelegate.Resolve

Click to expand...

Isn't there something missing following the close-parenthesis? A dot or a new-line or a bang or SOMETHING? That syntax cannot possibly be right as printed. But if this even compiled, I'm sure this has to be a transcription error.

True enough, it is a bad cut and paste job. It should read:
Set myDelegate= myItem.Recipeints.Add("email@domain.com")
myDelegate.Resolve (this checks the GAL for a match)

Works fine at home. Damn US Gov ONENet and the NCTS/N6 Nazis have it all locked down. I get it, being able to programmatically send e-mails with out the users having to manually intervene has proven troublesome in the past (remember the ILoveYou virus?).

I did read somewhere else that if I paid for and obtained an digital signature and package it with the FE and then the owner of the FE include it in the Trust Center, then it would work.

But again, even if that were accurate, I would still need NCTS approval to do this and the juice just aint worth the squeeze...

The only reason this works for me is that I have never had to send a task to someone else. When user X runs my FE file, I build the task for user X, so in essence he is doing it to himself (because, of course, the FE runs in the user's context). I can't send tasks to anyone here on the NMCI network either.