Tables and relationships?
in [Tables]
|
Prev: Access Log in
Next: How do you normalize a table?
From: awsmitty on 16 Jan 2010 23:03 First, the overall objective. A few others and I work in a dispatch office in a homeless shelter. (I will just be upfront about it.) We are responsible for … scheduling the trucks to pickup donations, keeping track of pending pickup and the expected items, and keeping track of past donations incase the IRS questions the legitimacy. I, for the life of me, cannot figure out the necessary tables and their relationships. Here is what I'm thinking. There are four trucks, so, tblTrucks, which has only one field (and an index field), trucks, A, B, C, and D. There needs to be a table which lists the items, and there are many, beds, sofas, lamps, bags of clothes, lawn mowers, bikes, … I have 38 items, and a memo box to cover the loose ends, all of these would be the fields. The records would be, for example, 1-3 bags of clothes or 6-9, 9-12, 12+, or for beds, fields like twin, full, queen, king, crib, twin with rails, headboard, etc. Most of these once on the final ticket, would be simple integers, 1 sofa, 3 lamps, so most of the fields would be 1,2,3, … and the thought is to have these ultimately put on a form as combo boxes. (I hope this is making sense!) There is a table of map grids. The drivers navigate via maps grids so this table contains things like street, city, zip, hundred block, and of course, the map grid, which truck(s) covers that map grid, and this is called tblMapGrid. So, thus far, a tblMapGrid, tblTrucks, tblItems that the truck picks up, these items obviously are common both truck and donor, and of course the address is also common to the donor. Which brings us to the next to the last table, one for the donor, not much left, name, phone(s), that's about it, but I was also going to include on this table call date, pickup date, ticket number, special pickup instructions, and this is called tblPatrons. Finally the last table, which is a composite of all of the above, tblDonations, the records of which would printed out the day of the pickups and serve the driver, who hands it to the patron as a receipt, which is also stored here for tax purposes. If you're like me, I'm saying to myself, “What a sha-bang”, but that is what I'm thinking. I am open to criticism, suggestions, alterations, or dump the whole thing and start over. The above is bad enough, but now the relationships. I can see the relationship between the tblDonations and all the rest of the tables. That's easy, and I'm hoping that's enough. So, envision tblDonations in the center with four spokes coming of, on for each remaining table. Or, should it be tblDonations related to truck, related to mapgrid, related to patron, related to items. Or, does it really matter? I don't want to sound stupid, but I really don't know. I am new; this is my very first at Access. I think you may also need what I'm shooting for as the final “product”, or form. I'm hoping for one form with eight tabs, tab1, given the street address, search for and find the corresponding map grid and truck. This is already done. Tab2, a place were the final “ticket” is prepared, This would be temporarily stored until the date of the pickup and would be identical to the records of tblDonations, and this table is were it would be permanently stored. (As you can probably see, I am hoping this is done “on the fly”, in other words, as the donor is on the phone this whole thing is filled out.) Tab3, simple, today's schedule, for all 4 trucks, on one form. Each record printed off the morning of the pickup and given to the driver. Tab4, same thing except for tomorrow. Tab5-8, the schedule for each truck as far into the future as I can get. These may be datasheet, something I can scroll from top to bottom. So, there's were I'm at. If anyone could comment on the tables, their relationships, or just the overall structure it would be appreciated. Thanks I will try next time not to be so wordy, it's just that I need to remove this from my head and put it into yours, as accurately as possible. -- awsmitty
From: Tom van Stiphout on 17 Jan 2010 01:17 On Sat, 16 Jan 2010 20:03:01 -0800, awsmitty <awsmitty(a)discussions.microsoft.com> wrote: An ambitious project for a newbie. I will focus on one aspect. You write: "There needs to be a table which lists the items, and there are many, beds, sofas, lamps, bags of clothes, lawn mowers, bikes, � I have 38 items, and a memo box to cover the loose ends, all of these would be the fields." So I think you want to create: tblItems Bed Sofa Lamp BagOfClothes ....etc... LooseEnds That is a REALLY BAD idea, for many reasons. In a relational database you typically have more rows and fewer columns: tblItems ItemID autonumber PK ItemName text required uniqueindex This is the stock list of your 38 items. Or if next month we want to add an item, simply add one more row to this table and EVERYTHING else stays the same. tblDonations DonationID autonumber PK DonationDate datetime, required DonorID (link to Donors table) This sets up a classic M:M (many-to-many) relationship: each item is in many donations, and each donation has many items. This is resolved with a third table: tblItemsInDonations ItemID long int PK DonationID long int PK Quantity single required Then in the Relationships window you create the two 1:M relationships between tblItems.ItemID and tblItemsInDonations.ItemID as well as tblDonations.DonationID and tblItemsInDonations.DonationID, and you enforce the relationships. Now you have a structure you can build upon. For example you can create a form in formview with recordsource based on tblDonations, and a subform (set LinkMasterFields and LinkChildFields both to DonationID) based on tblItemsInDonations with a hidden DonationID, a dropdown based on tblItems that is bound to the ItemID, and a textfield for Quantity. -Tom. Microsoft Access MVP >First, the overall objective. A few others and I work in a dispatch office >in a homeless shelter. (I will just be upfront about it.) We are >responsible for � scheduling the trucks to pickup donations, keeping track of >pending pickup and the expected items, and keeping track of past donations >incase the IRS questions the legitimacy. > >I, for the life of me, cannot figure out the necessary tables and their >relationships. Here is what I�m thinking. There are four trucks, so, >tblTrucks, which has only one field (and an index field), trucks, A, B, C, >and D. There needs to be a table which lists the items, and there are many, >beds, sofas, lamps, bags of clothes, lawn mowers, bikes, � I have 38 items, >and a memo box to cover the loose ends, all of these would be the fields. >The records would be, for example, 1-3 bags of clothes or 6-9, 9-12, 12+, or >for beds, fields like twin, full, queen, king, crib, twin with rails, >headboard, etc. Most of these once on the final ticket, would be simple >integers, 1 sofa, 3 lamps, so most of the fields would be 1,2,3, � and the >thought is to have these ultimately put on a form as combo boxes. (I hope >this is making sense!) There is a table of map grids. The drivers navigate >via maps grids so this table contains things like street, city, zip, hundred >block, and of course, the map grid, which truck(s) covers that map grid, and >this is called tblMapGrid. So, thus far, a tblMapGrid, tblTrucks, tblItems >that the truck picks up, these items obviously are common both truck and >donor, and of course the address is also common to the donor. Which brings >us to the next to the last table, one for the donor, not much left, name, >phone(s), that�s about it, but I was also going to include on this table call >date, pickup date, ticket number, special pickup instructions, and this is >called tblPatrons. Finally the last table, which is a composite of all of >the above, tblDonations, the records of which would printed out the day of >the pickups and serve the driver, who hands it to the patron as a receipt, >which is also stored here for tax purposes. If you�re like me, I�m saying to >myself, �What a sha-bang�, but that is what I�m thinking. > >I am open to criticism, suggestions, alterations, or dump the whole thing >and start over. The above is bad enough, but now the relationships. I can >see the relationship between the tblDonations and all the rest of the tables. > That�s easy, and I�m hoping that�s enough. So, envision tblDonations in the >center with four spokes coming of, on for each remaining table. Or, should >it be tblDonations related to truck, related to mapgrid, related to patron, >related to items. Or, does it really matter? I don�t want to sound stupid, >but I really don�t know. I am new; this is my very first at Access. > >I think you may also need what I�m shooting for as the final �product�, or >form. I�m hoping for one form with eight tabs, tab1, given the street >address, search for and find the corresponding map grid and truck. This is >already done. Tab2, a place were the final �ticket� is prepared, This would >be temporarily stored until the date of the pickup and would be identical to >the records of tblDonations, and this table is were it would be permanently >stored. (As you can probably see, I am hoping this is done �on the fly�, in >other words, as the donor is on the phone this whole thing is filled out.) >Tab3, simple, today�s schedule, for all 4 trucks, on one form. Each record >printed off the morning of the pickup and given to the driver. Tab4, same >thing except for tomorrow. Tab5-8, the schedule for each truck as far into >the future as I can get. These may be datasheet, something I can scroll from >top to bottom. > >So, there�s were I�m at. If anyone could comment on the tables, their >relationships, or just the overall structure it would be appreciated. > >Thanks > >I will try next time not to be so wordy, it's just that I need to remove >this from my head and put it into yours, as accurately as possible.
From: awsmitty on 17 Jan 2010 16:12 -- awsmitty "Tom van Stiphout" wrote: > On Sat, 16 Jan 2010 20:03:01 -0800, awsmitty > <awsmitty(a)discussions.microsoft.com> wrote: > > An ambitious project for a newbie. > > I will focus on one aspect. You write: > "There needs to be a table which lists the items, and there are many, > beds, sofas, lamps, bags of clothes, lawn mowers, bikes, … I have 38 > items, and a memo box to cover the loose ends, all of these would be > the fields." > So I think you want to create: > tblItems > Bed > Sofa > Lamp > BagOfClothes > ....etc... > LooseEnds > > That is a REALLY BAD idea, for many reasons. In a relational database > you typically have more rows and fewer columns: > tblItems > ItemID autonumber PK > ItemName text required uniqueindex > This is the stock list of your 38 items. Or if next month we want to > add an item, simply add one more row to this table and EVERYTHING else > stays the same. > > tblDonations > DonationID autonumber PK > DonationDate datetime, required > DonorID (link to Donors table) > > This sets up a classic M:M (many-to-many) relationship: each item is > in many donations, and each donation has many items. This is resolved > with a third table: > tblItemsInDonations > ItemID long int PK > DonationID long int PK > Quantity single required > > Then in the Relationships window you create the two 1:M relationships > between tblItems.ItemID and tblItemsInDonations.ItemID as well as > tblDonations.DonationID and tblItemsInDonations.DonationID, and you > enforce the relationships. > > Now you have a structure you can build upon. For example you can > create a form in formview with recordsource based on tblDonations, and > a subform (set LinkMasterFields and LinkChildFields both to > DonationID) based on tblItemsInDonations with a hidden DonationID, a > dropdown based on tblItems that is bound to the ItemID, and a > textfield for Quantity. > > -Tom. > Microsoft Access MVP > > > >First, the overall objective. A few others and I work in a dispatch office > >in a homeless shelter. (I will just be upfront about it.) We are > >responsible for … scheduling the trucks to pickup donations, keeping track of > >pending pickup and the expected items, and keeping track of past donations > >incase the IRS questions the legitimacy. > > > >I, for the life of me, cannot figure out the necessary tables and their > >relationships. Here is what I'm thinking. There are four trucks, so, > >tblTrucks, which has only one field (and an index field), trucks, A, B, C, > >and D. There needs to be a table which lists the items, and there are many, > >beds, sofas, lamps, bags of clothes, lawn mowers, bikes, … I have 38 items, > >and a memo box to cover the loose ends, all of these would be the fields. > >The records would be, for example, 1-3 bags of clothes or 6-9, 9-12, 12+, or > >for beds, fields like twin, full, queen, king, crib, twin with rails, > >headboard, etc. Most of these once on the final ticket, would be simple > >integers, 1 sofa, 3 lamps, so most of the fields would be 1,2,3, … and the > >thought is to have these ultimately put on a form as combo boxes. (I hope > >this is making sense!) There is a table of map grids. The drivers navigate > >via maps grids so this table contains things like street, city, zip, hundred > >block, and of course, the map grid, which truck(s) covers that map grid, and > >this is called tblMapGrid. So, thus far, a tblMapGrid, tblTrucks, tblItems > >that the truck picks up, these items obviously are common both truck and > >donor, and of course the address is also common to the donor. Which brings > >us to the next to the last table, one for the donor, not much left, name, > >phone(s), that's about it, but I was also going to include on this table call > >date, pickup date, ticket number, special pickup instructions, and this is > >called tblPatrons. Finally the last table, which is a composite of all of > >the above, tblDonations, the records of which would printed out the day of > >the pickups and serve the driver, who hands it to the patron as a receipt, > >which is also stored here for tax purposes. If you're like me, I'm saying to > >myself, “What a sha-bang”, but that is what I'm thinking. > > > >I am open to criticism, suggestions, alterations, or dump the whole thing > >and start over. The above is bad enough, but now the relationships. I can > >see the relationship between the tblDonations and all the rest of the tables. > > That's easy, and I'm hoping that's enough. So, envision tblDonations in the > >center with four spokes coming of, on for each remaining table. Or, should > >it be tblDonations related to truck, related to mapgrid, related to patron, > >related to items. Or, does it really matter? I don't want to sound stupid, > >but I really don't know. I am new; this is my very first at Access. > > > >I think you may also need what I'm shooting for as the final “product”, or > >form. I'm hoping for one form with eight tabs, tab1, given the street > >address, search for and find the corresponding map grid and truck. This is > >already done. Tab2, a place were the final “ticket” is prepared, This would > >be temporarily stored until the date of the pickup and would be identical to > >the records of tblDonations, and this table is were it would be permanently > >stored. (As you can probably see, I am hoping this is done “on the fly”, in > >other words, as the donor is on the phone this whole thing is filled out.) > >Tab3, simple, today's schedule, for all 4 trucks, on one form. Each record > >printed off the morning of the pickup and given to the driver. Tab4, same > >thing except for tomorrow. Tab5-8, the schedule for each truck as far into > >the future as I can get. These may be datasheet, something I can scroll from > >top to bottom. > > > >So, there's were I'm at. If anyone could comment on the tables, their > >relationships, or just the overall structure it would be appreciated. > > > >Thanks > > > >I will try next time not to be so wordy, it's just that I need to remove > >this from my head and put it into yours, as accurately as possible. > . >
From: awsmitty on 17 Jan 2010 16:15 Tom, Many thanks. Yes, I would agree, this is a bit ambitious for a newbie. I am up to my neck, but I really think it has to be done. If I leave here and it doesn't get done, it will be a long time before someone else approaches the issue. The current method is slow, awkward, very error prone, and just plain sloppy. For example, we have a closet full of carbon copies of past receipts that we must keep. When's that last time you've even seen a carbon copy, much less used one? I could go on and on. I see what you're doing with the items table. I figured that 38+ fields with a dozen rows at most was a bad idea, but I couldn't figure out any other way. What drew me towards this were things like the beds. Using your example, I guess I could also have a table linked to beds, which contains all the possibilities, twin, full, qn, etc, along with mattress, box spring, rails, headboard, etc. Sometimes we get it all, sometimes we only get one piece. Continuing with your example, I will try to set this up, massage it as best I can, and let you know the progress. I already know part of what's going to happen. I am going to make one form, throw it out, make another, throw it out, and continue this way until the end result is a db that is very simple to use. There is still much for me to learn. I got the search routine to work. But filling out the rest of the tabs as described in the posting above, in such a manner that it is as user friendly as possible, is still somewhat unresolved. That's another reason why all the items, etc. When the smoke clears, this really does need to be very simple to use. Thanks again -- awsmitty "Tom van Stiphout" wrote: > On Sat, 16 Jan 2010 20:03:01 -0800, awsmitty > <awsmitty(a)discussions.microsoft.com> wrote: > > An ambitious project for a newbie. > > I will focus on one aspect. You write: > "There needs to be a table which lists the items, and there are many, > beds, sofas, lamps, bags of clothes, lawn mowers, bikes, … I have 38 > items, and a memo box to cover the loose ends, all of these would be > the fields." > So I think you want to create: > tblItems > Bed > Sofa > Lamp > BagOfClothes > ....etc... > LooseEnds > > That is a REALLY BAD idea, for many reasons. In a relational database > you typically have more rows and fewer columns: > tblItems > ItemID autonumber PK > ItemName text required uniqueindex > This is the stock list of your 38 items. Or if next month we want to > add an item, simply add one more row to this table and EVERYTHING else > stays the same. > > tblDonations > DonationID autonumber PK > DonationDate datetime, required > DonorID (link to Donors table) > > This sets up a classic M:M (many-to-many) relationship: each item is > in many donations, and each donation has many items. This is resolved > with a third table: > tblItemsInDonations > ItemID long int PK > DonationID long int PK > Quantity single required > > Then in the Relationships window you create the two 1:M relationships > between tblItems.ItemID and tblItemsInDonations.ItemID as well as > tblDonations.DonationID and tblItemsInDonations.DonationID, and you > enforce the relationships. > > Now you have a structure you can build upon. For example you can > create a form in formview with recordsource based on tblDonations, and > a subform (set LinkMasterFields and LinkChildFields both to > DonationID) based on tblItemsInDonations with a hidden DonationID, a > dropdown based on tblItems that is bound to the ItemID, and a > textfield for Quantity. > > -Tom. > Microsoft Access MVP > > > >First, the overall objective. A few others and I work in a dispatch office > >in a homeless shelter. (I will just be upfront about it.) We are > >responsible for … scheduling the trucks to pickup donations, keeping track of > >pending pickup and the expected items, and keeping track of past donations > >incase the IRS questions the legitimacy. > > > >I, for the life of me, cannot figure out the necessary tables and their > >relationships. Here is what I'm thinking. There are four trucks, so, > >tblTrucks, which has only one field (and an index field), trucks, A, B, C, > >and D. There needs to be a table which lists the items, and there are many, > >beds, sofas, lamps, bags of clothes, lawn mowers, bikes, … I have 38 items, > >and a memo box to cover the loose ends, all of these would be the fields. > >The records would be, for example, 1-3 bags of clothes or 6-9, 9-12, 12+, or > >for beds, fields like twin, full, queen, king, crib, twin with rails, > >headboard, etc. Most of these once on the final ticket, would be simple > >integers, 1 sofa, 3 lamps, so most of the fields would be 1,2,3, … and the > >thought is to have these ultimately put on a form as combo boxes. (I hope > >this is making sense!) There is a table of map grids. The drivers navigate > >via maps grids so this table contains things like street, city, zip, hundred > >block, and of course, the map grid, which truck(s) covers that map grid, and > >this is called tblMapGrid. So, thus far, a tblMapGrid, tblTrucks, tblItems > >that the truck picks up, these items obviously are common both truck and > >donor, and of course the address is also common to the donor. Which brings > >us to the next to the last table, one for the donor, not much left, name, > >phone(s), that's about it, but I was also going to include on this table call > >date, pickup date, ticket number, special pickup instructions, and this is > >called tblPatrons. Finally the last table, which is a composite of all of > >the above, tblDonations, the records of which would printed out the day of > >the pickups and serve the driver, who hands it to the patron as a receipt, > >which is also stored here for tax purposes. If you're like me, I'm saying to > >myself, “What a sha-bang”, but that is what I'm thinking. > > > >I am open to criticism, suggestions, alterations, or dump the whole thing > >and start over. The above is bad enough, but now the relationships. I can > >see the relationship between the tblDonations and all the rest of the tables. > > That's easy, and I'm hoping that's enough. So, envision tblDonations in the > >center with four spokes coming of, on for each remaining table. Or, should > >it be tblDonations related to truck, related to mapgrid, related to patron, > >related to items. Or, does it really matter? I don't want to sound stupid, > >but I really don't know. I am new; this is my very first at Access. > > > >I think you may also need what I'm shooting for as the final “product”, or > >form. I'm hoping for one form with eight tabs, tab1, given the street > >address, search for and find the corresponding map grid and truck. This is > >already done. Tab2, a place were the final “ticket” is prepared, This would > >be temporarily stored until the date of the pickup and would be identical to > >the records of tblDonations, and this table is were it would be permanently > >stored. (As you can probably see, I am hoping this is done “on the fly”, in > >other words, as the donor is on the phone this whole thing is filled out.) > >Tab3, simple, today's schedule, for all 4 trucks, on one form. Each record > >printed off the morning of the pickup and given to the driver. Tab4, same > >thing except for tomorrow. Tab5-8, the schedule for each truck as far into > >the future as I can get. These may be datasheet, something I can scroll from > >top to bottom. > > > >So, there's were I'm at. If anyone could comment on the tables, their > >relationships, or just the overall structure it would be appreciated. > > > >Thanks > > > >I will try next time not to be so wordy, it's just that I need to remove > >this from my head and put it into yours, as accurately as possible. > . >
From: awsmitty on 17 Jan 2010 16:39
Tom. At the end of the forth paragraph, you mention"quantity single required". I have to ask, what do you mean? -- awsmitty "Tom van Stiphout" wrote: > On Sat, 16 Jan 2010 20:03:01 -0800, awsmitty > <awsmitty(a)discussions.microsoft.com> wrote: > > An ambitious project for a newbie. > > I will focus on one aspect. You write: > "There needs to be a table which lists the items, and there are many, > beds, sofas, lamps, bags of clothes, lawn mowers, bikes, … I have 38 > items, and a memo box to cover the loose ends, all of these would be > the fields." > So I think you want to create: > tblItems > Bed > Sofa > Lamp > BagOfClothes > ....etc... > LooseEnds > > That is a REALLY BAD idea, for many reasons. In a relational database > you typically have more rows and fewer columns: > tblItems > ItemID autonumber PK > ItemName text required uniqueindex > This is the stock list of your 38 items. Or if next month we want to > add an item, simply add one more row to this table and EVERYTHING else > stays the same. > > tblDonations > DonationID autonumber PK > DonationDate datetime, required > DonorID (link to Donors table) > > This sets up a classic M:M (many-to-many) relationship: each item is > in many donations, and each donation has many items. This is resolved > with a third table: > tblItemsInDonations > ItemID long int PK > DonationID long int PK > Quantity single required > > Then in the Relationships window you create the two 1:M relationships > between tblItems.ItemID and tblItemsInDonations.ItemID as well as > tblDonations.DonationID and tblItemsInDonations.DonationID, and you > enforce the relationships. > > Now you have a structure you can build upon. For example you can > create a form in formview with recordsource based on tblDonations, and > a subform (set LinkMasterFields and LinkChildFields both to > DonationID) based on tblItemsInDonations with a hidden DonationID, a > dropdown based on tblItems that is bound to the ItemID, and a > textfield for Quantity. > > -Tom. > Microsoft Access MVP > > > >First, the overall objective. A few others and I work in a dispatch office > >in a homeless shelter. (I will just be upfront about it.) We are > >responsible for … scheduling the trucks to pickup donations, keeping track of > >pending pickup and the expected items, and keeping track of past donations > >incase the IRS questions the legitimacy. > > > >I, for the life of me, cannot figure out the necessary tables and their > >relationships. Here is what I'm thinking. There are four trucks, so, > >tblTrucks, which has only one field (and an index field), trucks, A, B, C, > >and D. There needs to be a table which lists the items, and there are many, > >beds, sofas, lamps, bags of clothes, lawn mowers, bikes, … I have 38 items, > >and a memo box to cover the loose ends, all of these would be the fields. > >The records would be, for example, 1-3 bags of clothes or 6-9, 9-12, 12+, or > >for beds, fields like twin, full, queen, king, crib, twin with rails, > >headboard, etc. Most of these once on the final ticket, would be simple > >integers, 1 sofa, 3 lamps, so most of the fields would be 1,2,3, … and the > >thought is to have these ultimately put on a form as combo boxes. (I hope > >this is making sense!) There is a table of map grids. The drivers navigate > >via maps grids so this table contains things like street, city, zip, hundred > >block, and of course, the map grid, which truck(s) covers that map grid, and > >this is called tblMapGrid. So, thus far, a tblMapGrid, tblTrucks, tblItems > >that the truck picks up, these items obviously are common both truck and > >donor, and of course the address is also common to the donor. Which brings > >us to the next to the last table, one for the donor, not much left, name, > >phone(s), that's about it, but I was also going to include on this table call > >date, pickup date, ticket number, special pickup instructions, and this is > >called tblPatrons. Finally the last table, which is a composite of all of > >the above, tblDonations, the records of which would printed out the day of > >the pickups and serve the driver, who hands it to the patron as a receipt, > >which is also stored here for tax purposes. If you're like me, I'm saying to > >myself, “What a sha-bang”, but that is what I'm thinking. > > > >I am open to criticism, suggestions, alterations, or dump the whole thing > >and start over. The above is bad enough, but now the relationships. I can > >see the relationship between the tblDonations and all the rest of the tables. > > That's easy, and I'm hoping that's enough. So, envision tblDonations in the > >center with four spokes coming of, on for each remaining table. Or, should > >it be tblDonations related to truck, related to mapgrid, related to patron, > >related to items. Or, does it really matter? I don't want to sound stupid, > >but I really don't know. I am new; this is my very first at Access. > > > >I think you may also need what I'm shooting for as the final “product”, or > >form. I'm hoping for one form with eight tabs, tab1, given the street > >address, search for and find the corresponding map grid and truck. This is > >already done. Tab2, a place were the final “ticket” is prepared, This would > >be temporarily stored until the date of the pickup and would be identical to > >the records of tblDonations, and this table is were it would be permanently > >stored. (As you can probably see, I am hoping this is done “on the fly”, in > >other words, as the donor is on the phone this whole thing is filled out.) > >Tab3, simple, today's schedule, for all 4 trucks, on one form. Each record > >printed off the morning of the pickup and given to the driver. Tab4, same > >thing except for tomorrow. Tab5-8, the schedule for each truck as far into > >the future as I can get. These may be datasheet, something I can scroll from > >top to bottom. > > > >So, there's were I'm at. If anyone could comment on the tables, their > >relationships, or just the overall structure it would be appreciated. > > > >Thanks > > > >I will try next time not to be so wordy, it's just that I need to remove > >this from my head and put it into yours, as accurately as possible. > . > |