R
Rich
Guest
Access 95 used to come with a PIM db, search here to see if you can find a link to it
Creating Diaries/journal in Access?
- Thread starter A|ex
- Start date
- Local time
- Today, 01:30
- Joined
- Feb 28, 2001
- Messages
- 31,022
Now, I'm all for using Access when it is appropriate, but someone ignored a comment in passing that should not be ignored.
Outlook, ugly as it is and expensive as it is, has scheduling functions built-in and ready to run, working far better than re-inventing the wheel, and it works even in a big environment. Having the function there and ready to use can often be an incentive for stepping up to a newer version of Office. Not to mention that, as a member of Office, Outlook will participate in automation objects (COM methods) from Access just as cleanly as any other Office member would. (OK, OK, it's not saying that much, I know, but from a business standpoint, sometimes BUY is cheaper than MAKE.)
The problem with Access doing scheduling is, of course, that scheduling is a SPARSE activity. I.e. data density is low when compared to the places where data COULD be stored. Or, stated another way, SPARSE data has gaps in it. Excel and Outlook don't care, their storage paradigm allows this. But Access datasheets require something to be there in order to be displayed, and this is where "sparse" becomes a problem. I'm not saying you can't do it. But it is a problem.
Here's another way-out thought. Use EXCEL to store the appointments for a week. EXCEL likes sparse data very well. Access can open an EXCEL spreadsheet as an application object, and can manipulate its contents pretty easily. I'm a firm believer in using existing tools to the hilt and developing the minimum extra stuff required to get the job done.
Outlook, ugly as it is and expensive as it is, has scheduling functions built-in and ready to run, working far better than re-inventing the wheel, and it works even in a big environment. Having the function there and ready to use can often be an incentive for stepping up to a newer version of Office. Not to mention that, as a member of Office, Outlook will participate in automation objects (COM methods) from Access just as cleanly as any other Office member would. (OK, OK, it's not saying that much, I know, but from a business standpoint, sometimes BUY is cheaper than MAKE.)
The problem with Access doing scheduling is, of course, that scheduling is a SPARSE activity. I.e. data density is low when compared to the places where data COULD be stored. Or, stated another way, SPARSE data has gaps in it. Excel and Outlook don't care, their storage paradigm allows this. But Access datasheets require something to be there in order to be displayed, and this is where "sparse" becomes a problem. I'm not saying you can't do it. But it is a problem.
Here's another way-out thought. Use EXCEL to store the appointments for a week. EXCEL likes sparse data very well. Access can open an EXCEL spreadsheet as an application object, and can manipulate its contents pretty easily. I'm a firm believer in using existing tools to the hilt and developing the minimum extra stuff required to get the job done.
Hi Guys,
I don't disagree with anything said. In my mind it really depends on how customized your scheduling needs are. Ours happend to be very cusomized, since the schedule was develoepd for a large physician practice to schedule patient vists for multiple physicians using multiple resources at multiple sites. We needed built in visit types, an ability to block out slots over the next year by provider, alerts when you try to book a patient who might owe you money or who has missed several apointments, an ability to view the patients insurance info when scheduling an appointment, end-of-day print outs of who missed appts, etc.. We needed to print schedules not only by day, but by the patient's health insurance plans and co-payments due, ect... It was also very important to use to keep the schedule component integrated within the full electronic medical record application, and not require users to go back to their desktop to schedule appts. By integrating within the full application, we could also easily draw on appointment history info in other areas of the program
Anyway, you get the idea, so although I definetely agree outlook is a good tool for basic scheduling needs, I also think that it can be appropriate at times to build it within access.
Anyway, just my 2 cents
Thanks
Jackson
I don't disagree with anything said. In my mind it really depends on how customized your scheduling needs are. Ours happend to be very cusomized, since the schedule was develoepd for a large physician practice to schedule patient vists for multiple physicians using multiple resources at multiple sites. We needed built in visit types, an ability to block out slots over the next year by provider, alerts when you try to book a patient who might owe you money or who has missed several apointments, an ability to view the patients insurance info when scheduling an appointment, end-of-day print outs of who missed appts, etc.. We needed to print schedules not only by day, but by the patient's health insurance plans and co-payments due, ect... It was also very important to use to keep the schedule component integrated within the full electronic medical record application, and not require users to go back to their desktop to schedule appts. By integrating within the full application, we could also easily draw on appointment history info in other areas of the program
Anyway, you get the idea, so although I definetely agree outlook is a good tool for basic scheduling needs, I also think that it can be appropriate at times to build it within access.
Anyway, just my 2 cents
Thanks
Jackson
greaseman
Closer to seniority!
- Local time
- Today, 01:30
- Joined
- Jan 6, 2003
- Messages
- 360
And for what it's worth....that's what we're looking for at my client's site. Something that provides scheduling ability for multiple people on possibly multiple tasks at multiple sites. I too don't agree with anything discussed but don't think my clients would want the Outlook / Calendar approach. Nor do they want anything looking like or behaving like Project. I'm continuing pursuit of the possible Access approach, if others are still interested. The comments and replies are both interesting and appreciated.
Diary
Did anything come of this co-op. Looks like getting a good diary is still pretty elusive. I have tried the one referred to in Utteraccess.com and it would fit my needs but it seems flawed. I have sent off some queries on it and hope to hear back.
Did anything come of this co-op. Looks like getting a good diary is still pretty elusive. I have tried the one referred to in Utteraccess.com and it would fit my needs but it seems flawed. I have sent off some queries on it and hope to hear back.
M
Mike375
Guest
So if we are telemarkerting can we use the appointment maker in Outlook? I have never seen or used it.
If I could use OutLook for that it would shave this DB down in size real quick.
Is there a way to use Outlook so it links to the record selection done by Access and allow for the telemarketer to make calls/appointments for more than one salesman during the day.
If you can tell me Outlook does it or can do it then let me know. I am currently helping a friend make a DB that is essentially the same as I have but since it is from "the ground up" we are trying to meet Access rules. That is all OK. However, we are not far away from installing the diary system..if that can be done by outlook.....that will save huge amounts of work. The reason that putting the diary system in is a lot of work is because field names for instance have been changed.....no more CL Surname, Client Suburb etc and in many instances (except SetValue) macros repaced with code.
M
Mike375
Guest
Thanks for your response.
My guess is that outlook would be fine for a stand alone diary. However, I am only guessing (never used it), but no harm in asking.
Similar threads
