Hi,

I would like to make Users a special subset of contacts, because most of our scheduling is contact-based rather than user-based. In fact, for the time being most of the "users" will not actually be using the database, but the initials feature seems so handy for the person actually using the database, I'm reluctant to give it up, and I'd like to keep the option of having users enter their own appointments some time in the future.

I'm thinking of setting up a one-to-one relationship with Contacts, but I'm stumped as to where to go from there. I'd be really grateful for suggestions.

Hi, We've tied used to contacts any number of ways, but I'm not sure I'm following this enough to know what you'd like this change to accomplish. Can you post some more details?

Hi John,

Scheduling is very important in our business. We are a group of interpreters who organize interpreting teams. We need to track in-house availability and assignments, and also availability of non-member interpreters (and, occasionally, other types of contacts.

This database is currently planned as a single-user setup for one secretary to run, backed up by two members on holidays and the like - but I'm getting ambitious and feel it would be great, eventually, if our own members could input their own schedule details.

Beyond that, for teams that we put together there is always one member in charge of the team, whether that person is part of the team or not. I thought it would make sense to enter that using the user initials feature, but the more I think about it the more I figure it makes more sense to simply have optional initials for contacts, a value list for our members' initials to use in a checkbox field in lieu of the users value list, and change the appointment input layout (and relationships?) accordingly.

My current thinking is that the tying-in of users to contacts can be left for whenever we decide to step up to a hosted online solution. We're not quite ready for that now.

Thanks for triggering this reflection process and for designing this awesome software. I'd love to receive any pointers you might come up with. My obsession is convenient data entry, which means working very hard on the interface.

Sounds very cool: and thanks for the background. The simplest thing is to leave the user's table etc along and just link users to contacts via their initials. This means that when you add a new member you'd need to add them to the users section as well, but it means you have to make very few edits to the software.

You'd simply add a new field to the contacts table in which to store the contact's initials-- only contacts who are "members" would have these "member's initials". You could then use a relationship from CalDailyAppointments to a new instance of Contacts called something like CalDailyApptUserContacts to show a member's phone number or other information on the appointment.

You can of course go further and remove the user's table, replacing all its table occurrences with instances of contacts that use relationships which only show users. That would remove the double entry for new members I mentioned above. Aside from that, though, I don't think it gets you much for all the work.

The double entry isn't a real problem, we don't have droves of members coming in and, more importantly, anyone who joins as a member will be in the database as a contact long before joining.

Thanks for your awesome advice.

Now I'm trying to decide whether I should use your Projects table for our interpreting assignments, adding fields to Projects and dispensing with Gantt chart displays which are mostly irrelevant, or whether it's better to leave in Projects - against the day we might have other types of projects that we do want to track - in which case I would simply remove references to the Gantt chart layout in the navigation scheme but leave in the fields and calcs just in case.

In the second case, I would expect to make Jobs a subset of Projects, possibly by setting up a one-to-one relationship for all the highly specific fields and calculations required for interpreting jobs.

May I continue to pick your brain on this matter?

Not sure I know where to steer you here, but I can tell you the things I'd keep in mind when evaluating this...

You can filter the calendar by project (and see a list of projects per contact) so using the projects table as your jobs table starts to make sense if you have multiple appointments (activity records) per job. The extra fields and calcs added to the project table don't bother me, even if only some of your project records are interpreting jobs, though making a 1-to-1 here to unweight projects makes sense if you'll have tons of projects, only some of them interpreting jobs.

If you only have one appointment / activity per job, you might make the appointment your "job" record... actually making a 1-to-1 relationship between a new jobs table and appointments to keep the weight out of the appointments table.

By all means remove the references to gantt on the layouts, but keep the structures in place as it is a handy display if you ever need it.

Hope that helps.