SEVERE problems with VB/CDO/ADO/Exchange

Hello,

I've stumbled into a frustrating problem while developing a solution for a
local Hospital.

The solution involves programming in VB6 with Exchange2000 Server and
Outlook2002 and is aimed at maintaining the calendars of therapists and
patients online in Outlook. There are a few dozen therapists working with
this system in a network of over 70 Win2000 desktops (with two Win2000
servers) in the hospital.


Description:

1. Each therapist in the hospital has his own mailbox.
2. Each patient (out of a selected group of patients) has his own mailbox.
3. All of the above users use a custom Appointment Outlook form
"therapistMeeting" (published in the Organizational
Forms Library), which has an additional tab in it for the therapist to enter
treatment-related data. This extra data is stored in UserProperties fields
(via VBScript).
4. There's a person ("calendars manager") that is responsible for managing
the patients' calendars. This calendar manager sends meeting requests from
the patient's calendar to the therapist for setting up a treatment (either
one-timed or as a recurring event).


VB solution:

The treatment information entered by the therapist needs to be reflected in
the patient's appointment item. Thus, once an hour I'm running a VB program
(on the server) that synchronizes the calendars. This program uses the
Outlook Object Model in order to access MAPIFolder and AppointmentItem
objects of the patient, and when finding a meeting with a therapist, it
looks up this therapist's calendar folder (using GetSharedDefaultFolder) in
order to check the information that was entered and copy it into
the patient appointment item (i.e., into its UserProperties collection -
which would be reflected in the custom form's controls).

The synchronization program is written in Visual Basic 6.0 and is using CDO
1.21 and Outlook 10.0 Object Library. In addition to syncing the calendars,
this program also keeps the gathered data in SQL Server (version 7) tables
which are used later for reports generation. I've made sure that all object
references are set to Nothing when they're not needed anymore (including in
the
end of all "For Each" loops accompanied with a DoEvents command, in order to
help the garbage collector do its work during the loop and not take up lots
of memory).


At first it seemed that this solution works well, but then I've started
stumbling into the following highly-distressing problems:


1. Certain meetings between a patient and a therapist show a problem in
their AppointmentItem's Recipients collection: Although the meeting is
between two persons, the Recipients collection shows only ONE recipient
which isn't the AppointmentItem's owner. For example: Patient P has a
meeting with Therapist T => When looking in P's AppointmentItem, its
Recipients collection contains only T, and when looking in T's
AppointmentItem, its Recipients collection contains only P.

When opening this meeting in Outlook, all seems okay (Scheduling tab shows
the two recipients), and right after opening it it seems as if the problem
was solved also from the VB point of view, i.e., the Recipients collection
got "fixed". Is this a known bug that is fixed by Outlook when manually
opening the appointments?

I've BYPASSed this bug by writing a "getFixedRecipients" function that
returns a correct Recipients collection by logically compensating for the
missing recipients.


2. When I access an AppointmentItem via VB, its VBScript code seems to run
as well. This is highly undesirable for us, since the VBScript code pops up
message-boxes to the user in response to some data-related situations. In an
attempt to bypass this problem, I've added a VBScript check that tests
whether the Outlook window is hidden (TypeName(Application.ActiveWindow) =
"Nothing") and avoids running anything if when hidden. This solution seems
to work for new appointments, but NOT for older ones (why?).


3. When opening an appointment item of a recurring meeting, I frequently get
the following error which is generated by Outlook (and waits for a manual
click on its message box): "Cannot read one instance of this recurring
appointment. Close any open appointments and try again, or recreate the
appointment". This error pops up even if I run the program at night, i.e.,
when there are no opened appointments anywhere.

When I open such a problematic recurring appointment in Outlook, I get that
warning once more, and afterwards it disappears both from ordinary work in
Outlook and from the sync program's point of view (until randomly popping up
again). Why is this happening? (Is Outlook compensating for another bug?)


4. After each run of the synchronization program, the STORE.EXE service
(Exchange Message Store) on the server claims more memory without releasing
it (memory leak). We have 1GB physical RAM in our server, and after a very
short while all of it fills up - which degrades the server's functionality
and enforces us to restart the Mesage Store service frequently (an act which
then
enforces restarting all opened Outlook programs over the entire network!).
The memory leak happens when I run the sync program either on the server, or
remotely on a desktop machine.

I've looked and found Knowledgebase article #326389 ("XADM: Memory Leak
Occurs When You Use CDO 1.21 in a MAPI
Session to Log On to a Mailbox") which describes exactly our situation and
which admits it being a bug. As the article suggests, we've installed the
"March 2003 Exchange 2000 Server Post-Service Pack 3 Rollup" on the Exchange
server, but the problem persists (in a somewhat slowed manner) and the
memory leak continues. Our EMSABP32.dll file on the server is 163,840 bytes
long and is of version 6.0.6396.1.

In a desperate attempt to bypass this problem, I've started converting the
sync program from Outlook-CDO to ADO (in conjunction with the
CDO.Appointment / CDO.iAttendees interfaces), but soon I've stumbled into a
new problem: How do I read/wrote UserProperties that were put using the
custom Outlook form?



As you can imagine, these severe problems have put the whole project into a
halt (the project involves lots of staff people in the hospital) - and we
urgently need any help we can get!


Thanks in advance,
Uri Inbar.