If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
Need advice - how should I set this up?
John Vinson wrote:
On Mon, 24 Oct 2005 13:38:04 -0700, justin wrote: Ok, so after reading everyones advice/suggestions, I've changed things up a bit, but I'm still having some troubles. Thanks for the help by the way, it helps; a lot! Anyway, here is how I have my tables set up currently. [AccomplishmentsTbl] ProjectID -- Foreign key number field linked to [ProjectInfoTbl].[ProjectID] in a 1-to-1 relationship So each Project can have exactly zero or one accomplishments? Never a second one? One to one relationships are VERY rare. Generally if it's truly a one to one, you can simply include the fields into the parent table. Acres DS Thin FuelBreaks Slash Prun RxBurn Plans&Assessment I&E And this looks like you're storing data in fieldnames. .... which may be OK if the fields are Boolean (yes/no) type, but you said they were number fields. All of those fields are number fields except the bottom two. users enter in the amount of each, if any was completed for that project. [...] Date Name Rename these fields: both Date and Name are reserved words. Although I've never run into problems with Access over using these names for fields (but there might be valid technical reasons to avoid them), another reason to rename them is that they are not very informative. Name of what? Date when what happened? Making the names suggestive of what data the fields contain will help you avoid putting the wrong information in there, or trying to link dissimilar items together. [...] Just to be clear: a foreign key is a field whose function is to provide a link to a Primary Key value in some other table. If the Primary Key in the "one" side table is Text, the foreign key must be Text; if it's Autonumber, it should be Long Integer. You're not storing *data* per se in foreign key fields, you're storing pointers to other tables. Sometimes people do store data in foreign key fields (things like part numbers, student ID numbers, etc.), on the basis that it saves a Table reference and allows you to avoid maintaining an extra field in the referenced Table, but I think it's a confusing practice, and I very rarely do it myself. Access makes it easy to set up keys in which the ONLY purpose of the foreign key is to point to the other Table, and I think you'll avoid lots of headaches if you use it only for that purpose. [...] I'm guessing that each Project will have a unique Project# - so that would be your natural key. .... and this would be the kind of situation in which I, too, would have the primary key perform two functions (identify a record, and identify a Project#). But try not to overdo it. Autonumber fields don't cost much (only 4 bytes per record). I think the first thing to do is to get clear in your mind how relationships work. THEN start thinking about the form! John W. Vinson[MVP] Before working on the Form, you can do a lot with Queries, even though the layout won't be as pretty as with a Form. Define Queries to display the kinds of information you want to get out of the database. If you can't get the Queries to work, maybe there's a problem with Table design. Actually, working with the Queries may guide you toward making improvements in your Tables (such as getting rid of redundant information). -- Vincent Johns Please feel free to quote anything I say here. |
#12
|
|||
|
|||
Need advice - how should I set this up?
Well thanks go out to both J.V and V.J, and R.B for that matter. I have spent
all day reading up on relationships and normalization, along with these forum posts. Thanks for the info. Now I need to spend some time processing all of this. I will have more questions, so stay tuned. thanks again! -Justin -- I''ve never used Access before. HELP! |
#13
|
|||
|
|||
Need advice - how should I set this up?
"John Vinson" wrote:
[AccomplishmentsTbl] ProjectID -- Foreign key number field linked to [ProjectInfoTbl].[ProjectID] in a 1-to-1 relationship So each Project can have exactly zero or one accomplishments? Never a second one? No, Projects can have various accomplishments, depending on the project. This table is intended to record how many of each were accomplished during the project. One to one relationships are VERY rare. Generally if it's truly a one to one, you can simply include the fields into the parent table. Acres DS Thin FuelBreaks Slash Prun RxBurn Plans&Assessment I&E And this looks like you're storing data in fieldnames. Not exactly, those are the field names, and the data that is to be stored is quantities of each. For example, a project was a total of 10 acres, and there were 5 DS achieved, and 5 thin achieved. [...] A better design might be a many to many relationship. You'ld have a small table of Activities: Activities ActivityID Autonumber Primary Key Activity Text e.g. "Thin", "RxBurn" and a resolver table ProjectAccomplishments: ProjectAccomplishments ProjectID Long Integer link to Projects ActivityID Long Integer link to Activities Amount Number where you fill in the amount Is something like this still necessary? [CommentsTbl] ID -- Foreign Key number field linked to [ProjectInfoTbl].[ProjectID] in a one to many relationship. the many being [CommentsTbl] Comments -- another Foreign Key Foreign key to... what? Shouldn't this just be a Text (or Memo if the comments will run over 255 bytes) field containing the text of the comment? Yes, it probably should be. Date Name Rename these fields: both Date and Name are reserved words. OK [GrantInfoTbl] GrantID -- Primary Key autonumber field linked to [ProjectInfoTbl].[GrantID] in an indeterminate relationship (not sure what that means exactly, or how to change it) You cannot ***EVER*** use an Autonumber as a foreign key. Primary key, yes - but it *SIMPLY WILL NOT WORK* as a foreign key, or the field that you link *to*. An Autonumber is uncontrollable and arbitrary. How are Grants related to Projects, in the real world? Will one Grant cover multiple projects, or will each Project use multiple grants, or both, or neither? As far as I know, one grant can have multiple projects associated with it, or just one, or none (the grant itself is the project). [...] [ProjectInfoTbl] GrantID -- Foreign Key number field linked to [GrantInfoTbl].[GrantID] in an indeterminate relationship. ProjectID -- Primary Key autonumber field linked as noted above. Project# -- Primary Key Stop. Hammer Time. A table can have ONLY ONE PRIMARY KEY. If the Project# is stable (won't be edited often or ever) and can be counted on to be unique, use *it* as the Primary Key and as the foreign key in every table which needs a link; using an autonumber is necessary only if you don't have a "natural" key. I'm guessing that each Project will have a unique Project# - so that would be your natural key. I think I'll need an autonumber, because sometimes projects get cancelled, or merged with other projects, so I can't rely on the project# field. District DistrictPriority ProjectName Extensions Request Awarded Practice This table stores the info related to the individual projects. [RecipientsTbl] ProjectID -- Foreign Key number field linked to [ProjectInfoTbl].[ProjectID] in a one to one relationship\ Again... you want each Project to have one, and only one, never any more, contacts? I doubt it! I think you want a one to many relationship. I guess projects can have more than one contact. It's not usually the case, but I've seen some with multiple addresses or names. Basically the recipient is the project. Meaning the recipient can either be an individual person recieving assistance on their land, or the recipient is a Home Owner's Association for example. This information is typically not only the contact persons info, but also the location of the project. Name StreetAddress City State ZipCode County Community PhoneNumber Fax [...] You'll probably want tables of Cities, States, Counties (perhaps all in one Zip table), and doubtless more. I don't know if that is really going to be necessary. [...] I think the first thing to do is to get clear in your mind how relationships work. THEN start thinking about the form! John W. Vinson[MVP] I agree, I'm going to go back into the db now and start working on these corrections. I'll post again once I move things around a bit, and reach another road block. Thanks again for the help. -Justin |
#14
|
|||
|
|||
Need advice - how should I set this up?
On Wed, 26 Oct 2005 07:44:06 -0700, justin
wrote: "John Vinson" wrote: [AccomplishmentsTbl] ProjectID -- Foreign key number field linked to [ProjectInfoTbl].[ProjectID] in a 1-to-1 relationship So each Project can have exactly zero or one accomplishments? Never a second one? No, Projects can have various accomplishments, depending on the project. This table is intended to record how many of each were accomplished during the project. But a one to one relationship, BY DEFINITION, means that you can have either zero or one record in the AccomplishmentsTbl for any record in Projects. See below... One to one relationships are VERY rare. Generally if it's truly a one to one, you can simply include the fields into the parent table. Acres DS Thin FuelBreaks Slash Prun RxBurn Plans&Assessment I&E And this looks like you're storing data in fieldnames. Not exactly, those are the field names, and the data that is to be stored is quantities of each. For example, a project was a total of 10 acres, and there were 5 DS achieved, and 5 thin achieved. And if, six months down the road, the big boss says that you need to include "Public education", "Powerline Protection", and three other things as accomplishments, what do you do? Redesign your table, all your queries, all your forms, all your reports? These values ARE DATA. They are not attributes of an accomplishment entity! An Accomplishment has two attributes (fields), in my opinion: what type of accomplishment it was (say creating a FuelBreak), and how many of them there were. "Fields are expensive, records are cheap". You'll have much better luck storing one count of accomplishments per record, rather than one count per field in a wide-flat table. [...] A better design might be a many to many relationship. You'ld have a small table of Activities: Activities ActivityID Autonumber Primary Key Activity Text e.g. "Thin", "RxBurn" and a resolver table ProjectAccomplishments: ProjectAccomplishments ProjectID Long Integer link to Projects ActivityID Long Integer link to Activities Amount Number where you fill in the amount Is something like this still necessary? I'd say... yes, it is. See above. snip areas of agreement [GrantInfoTbl] GrantID -- Primary Key autonumber field linked to [ProjectInfoTbl].[GrantID] in an indeterminate relationship (not sure what that means exactly, or how to change it) You cannot ***EVER*** use an Autonumber as a foreign key. Primary key, yes - but it *SIMPLY WILL NOT WORK* as a foreign key, or the field that you link *to*. An Autonumber is uncontrollable and arbitrary. How are Grants related to Projects, in the real world? Will one Grant cover multiple projects, or will each Project use multiple grants, or both, or neither? As far as I know, one grant can have multiple projects associated with it, or just one, or none (the grant itself is the project). OK, then you should have a GrantID primary key in the GrantInfoTbl, and a GrantID foreign key in that grant's associated Projects. There should not be (and cannot be) a ProjectID field in the Grants table since the field can only have one value, and you need multiple ones. If GrantInfoTbl.GrantID is an Autonumber, use a Long Integer GrantID in the projects table. [ProjectInfoTbl] GrantID -- Foreign Key number field linked to [GrantInfoTbl].[GrantID] in an indeterminate relationship. ProjectID -- Primary Key autonumber field linked as noted above. Project# -- Primary Key Stop. Hammer Time. A table can have ONLY ONE PRIMARY KEY. If the Project# is stable (won't be edited often or ever) and can be counted on to be unique, use *it* as the Primary Key and as the foreign key in every table which needs a link; using an autonumber is necessary only if you don't have a "natural" key. I'm guessing that each Project will have a unique Project# - so that would be your natural key. I think I'll need an autonumber, because sometimes projects get cancelled, or merged with other projects, so I can't rely on the project# field. ok... make the autonumber the primary key then, and put a unique Index on Project# to prevent having two records with the same value. District DistrictPriority ProjectName Extensions Request Awarded Practice This table stores the info related to the individual projects. [RecipientsTbl] ProjectID -- Foreign Key number field linked to [ProjectInfoTbl].[ProjectID] in a one to one relationship\ Again... you want each Project to have one, and only one, never any more, contacts? I doubt it! I think you want a one to many relationship. I guess projects can have more than one contact. It's not usually the case, but I've seen some with multiple addresses or names. Basically the recipient is the project. Meaning the recipient can either be an individual person recieving assistance on their land, or the recipient is a Home Owner's Association for example. This information is typically not only the contact persons info, but also the location of the project. It only takes one multiple address to cause big headaches if you enforce a one to one. Simply use an autonumber ContactID primary key, and ProjectID as the foreign key. Name StreetAddress City State ZipCode County Community PhoneNumber Fax [...] You'll probably want tables of Cities, States, Counties (perhaps all in one Zip table), and doubtless more. I don't know if that is really going to be necessary. Handy... but you're right, probably not necessary. If you don't mind your users typing "Multnomah" twenty times, and maybe "Multnoma" or "Mulnomah" a couple of times, you can just use text fields and textboxes. It's very easy though to just pick from a list if you have one. I agree, I'm going to go back into the db now and start working on these corrections. I'll post again once I move things around a bit, and reach another road block. Look forward to seeing you back! John W. Vinson[MVP] |
#15
|
|||
|
|||
Need advice - how should I set this up?
"John Vinson" wrote:
On Wed, 26 Oct 2005 07:44:06 -0700, justin wrote: "John Vinson" wrote: [AccomplishmentsTbl] ProjectID -- Foreign key number field linked to [ProjectInfoTbl].[ProjectID] in a 1-to-1 relationship So each Project can have exactly zero or one accomplishments? Never a second one? No, Projects can have various accomplishments, depending on the project. This table is intended to record how many of each were accomplished during the project. But a one to one relationship, BY DEFINITION, means that you can have either zero or one record in the AccomplishmentsTbl for any record in Projects. See below... I see now. I was confused with primary keys and foreign keys. I think I've sorted things out now. See below... One to one relationships are VERY rare. Generally if it's truly a one to one, you can simply include the fields into the parent table. Acres DS Thin FuelBreaks Slash Prun RxBurn Plans&Assessment I&E And this looks like you're storing data in fieldnames. Not exactly, those are the field names, and the data that is to be stored is quantities of each. For example, a project was a total of 10 acres, and there were 5 DS achieved, and 5 thin achieved. And if, six months down the road, the big boss says that you need to include "Public education", "Powerline Protection", and three other things as accomplishments, what do you do? Redesign your table, all your queries, all your forms, all your reports? Touché. Ok, I've conceded and I created the two tables like you suggested below. [...] A better design might be a many to many relationship. You'ld have a small table of Activities: Activities ActivityID Autonumber Primary Key Activity Text e.g. "Thin", "RxBurn" Form related question: when users are entering in the data for the project, how do I change the view so they see the actual Text (ie, "Thin") instead of the ActivityID? and a resolver table ProjectAccomplishments: ProjectAccomplishments ProjectID Long Integer link to Projects ActivityID Long Integer link to Activities Amount Number where you fill in the amount Is something like this still necessary? I'd say... yes, it is. See above. So, after doing this I no longer need my original AccomplishmentsTbl correct? snip areas of agreement [GrantInfoTbl] GrantID -- Primary Key autonumber field linked to [ProjectInfoTbl].[GrantID] in an indeterminate relationship (not sure what that means exactly, or how to change it) You cannot ***EVER*** use an Autonumber as a foreign key. Primary key, yes - but it *SIMPLY WILL NOT WORK* as a foreign key, or the field that you link *to*. An Autonumber is uncontrollable and arbitrary. How are Grants related to Projects, in the real world? Will one Grant cover multiple projects, or will each Project use multiple grants, or both, or neither? As far as I know, one grant can have multiple projects associated with it, or just one, or none (the grant itself is the project). OK, then you should have a GrantID primary key in the GrantInfoTbl, and a GrantID foreign key in that grant's associated Projects. There should not be (and cannot be) a ProjectID field in the Grants table since the field can only have one value, and you need multiple ones. If GrantInfoTbl.GrantID is an Autonumber, use a Long Integer GrantID in the projects table. Done and done. [ProjectInfoTbl] GrantID -- Foreign Key number field linked to [GrantInfoTbl].[GrantID] in an indeterminate relationship. ProjectID -- Primary Key autonumber field linked as noted above. Project# -- Primary Key Stop. A table can have ONLY ONE PRIMARY KEY. If the Project# is stable (won't be edited often or ever) and can be counted on to be unique, use *it* as the Primary Key and as the foreign key in every table which needs a link; using an autonumber is necessary only if you don't have a "natural" key. I'm guessing that each Project will have a unique Project# - so that would be your natural key. I think I'll need an autonumber, because sometimes projects get cancelled, or merged with other projects, so I can't rely on the project# field. ok... make the autonumber the primary key then, and put a unique Index on Project# to prevent having two records with the same value. Also done. [...] [RecipientsTbl] ProjectID -- Foreign Key number field linked to [ProjectInfoTbl].[ProjectID] in a one to one relationship\ Again... you want each Project to have one, and only one, never any more, contacts? I doubt it! I think you want a one to many relationship. I guess projects can have more than one contact. It's not usually the case, but I've seen some with multiple addresses or names. Basically the recipient is the project. Meaning the recipient can either be an individual person recieving assistance on their land, or the recipient is a Home Owner's Association for example. This information is typically not only the contact persons info, but also the location of the project. It only takes one multiple address to cause big headaches if you enforce a one to one. Simply use an autonumber ContactID primary key, and ProjectID as the foreign key. I agree, and I did. Name StreetAddress City State ZipCode County Community PhoneNumber Fax [...] You'll probably want tables of Cities, States, Counties (perhaps all in one Zip table), and doubtless more. I don't know if that is really going to be necessary. Handy... but you're right, probably not necessary. If you don't mind your users typing "Multnomah" twenty times, and maybe "Multnoma" or "Mulnomah" a couple of times, you can just use text fields and textboxes. It's very easy though to just pick from a list if you have one. Yea, that is definitely a nice feature to have, but since we are really only dealing with the state of Colorado, I don't think I'm asking too much of my fellow employees. Well, now that I've made these adjustments things seem to be working ok. I made a couple of test forms, entered some data, and everything looks like it's working the way I had visioned it. Although, I tried making just one big form with all the relavant tables included (just to see if things were working) and it wasn't working properly. In design view all the various fields were there, but when switching back to form view it just became a blank form. I assume this is because the way the relationships are set up doesn't allow for all the fields to be on one form? Maybe? When I pick 2 tables to make a form out of, everything works fine. Thanks again for all the help. I think, as long as my tables are now normalized, I can start working on the forms and reports. At least I hope I can. -Justin |
#16
|
|||
|
|||
Need advice - how should I set this up?
"John Vinson" wrote:
On Wed, 26 Oct 2005 07:44:06 -0700, justin wrote: "John Vinson" wrote: [AccomplishmentsTbl] ProjectID -- Foreign key number field linked to [ProjectInfoTbl].[ProjectID] in a 1-to-1 relationship [...] Acres DS Thin FuelBreaks Slash Prun RxBurn Plans&Assessment I&E [...] And if, six months down the road, the big boss says that you need to include "Public education", "Powerline Protection", and three other things as accomplishments, what do you do? Redesign your table, all your queries, all your forms, all your reports? These values ARE DATA. They are not attributes of an accomplishment entity! An Accomplishment has two attributes (fields), in my opinion: what type of accomplishment it was (say creating a FuelBreak), and how many of them there were. "Fields are expensive, records are cheap". You'll have much better luck storing one count of accomplishments per record, rather than one count per field in a wide-flat table. [...] A better design might be a many to many relationship. You'ld have a small table of Activities: Activities ActivityID Autonumber Primary Key Activity Text e.g. "Thin", "RxBurn" and a resolver table ProjectAccomplishments: ProjectAccomplishments ProjectID Long Integer link to Projects ActivityID Long Integer link to Activities Amount Number where you fill in the amount I forgot to ask in my other post. Those last to fields I have in my AccomplishmentsTbl, Plans&Assessment and I&E are not number fields, but rather text fields where the user inputs what it was that was done. So, how can I set up these two new tables to include those fields as text fields? Or is it not possible? Will I need to set up another table for those two fields and link it back to the Activities Table? |
#17
|
|||
|
|||
Need advice - how should I set this up?
On Thu, 27 Oct 2005 07:45:02 -0700, justin
wrote: Answers inline with trimming. I see now. I was confused with primary keys and foreign keys. I think I've sorted things out now. See below... Good... glad to have helped you through that particular thicket! A better design might be a many to many relationship. You'ld have a small table of Activities: Activities ActivityID Autonumber Primary Key Activity Text e.g. "Thin", "RxBurn" Form related question: when users are entering in the data for the project, how do I change the view so they see the actual Text (ie, "Thin") instead of the ActivityID? By putting a Combo Box on the subform which stores the ID while displaying the text. That's the most common use of combos. See the Orders form in the Northwind sample database - it displays the product name while storing the product ID. So, after doing this I no longer need my original AccomplishmentsTbl correct? Correct. If you have data in it already post back - that information can be salvaged and moved into the normalized table. Handy... but you're right, probably not necessary. If you don't mind your users typing "Multnomah" twenty times, and maybe "Multnoma" or "Mulnomah" a couple of times, you can just use text fields and textboxes. It's very easy though to just pick from a list if you have one. Yea, that is definitely a nice feature to have, but since we are really only dealing with the state of Colorado, I don't think I'm asking too much of my fellow employees. Well... I'd find it much easier to tab into a combo box, type "OT" and have the combo autofill Otero, and hit tab to go on than to type "Otero" over and over again. Ten minutes work on your part now will save hours of your and your colleagues' time during the life of the project. Well, now that I've made these adjustments things seem to be working ok. I made a couple of test forms, entered some data, and everything looks like it's working the way I had visioned it. Although, I tried making just one big form with all the relavant tables included (just to see if things were working) and it wasn't working properly. In design view all the various fields were there, but when switching back to form view it just became a blank form. I assume this is because the way the relationships are set up doesn't allow for all the fields to be on one form? Maybe? No. A form based on a Grand Master Query That Includes Everything is not going to be particularly useful, either for display or for data entry. With that many tables, the query will probably not be updateable (so you won't see the "new record", since you can't ADD a new record); and unless every single linked table contains data, you won't see the existing records either, since the Query will only show you those records which have data in all the tables. You can use "Outer Joins" to see more data (and that will probably be useful in generating Reports), but there is no benefit to doing so on a Form. You *CAN* see all the data (well, all the data which fits your screen) by using a Form with Subforms. It is not necessary to try to create the form you describe - it serves no purpose which cannot be served more easily using other techniques. When I pick 2 tables to make a form out of, everything works fine. Thanks again for all the help. I think, as long as my tables are now normalized, I can start working on the forms and reports. At least I hope I can. If you do need help, please feel free to post in the .forms or ..reports newsgroups. See you there, maybe! Good Luck! John W. Vinson[MVP] |
#18
|
|||
|
|||
Need advice - how should I set this up?
On Thu, 27 Oct 2005 09:40:16 -0700, justin
wrote: I forgot to ask in my other post. Those last to fields I have in my AccomplishmentsTbl, Plans&Assessment and I&E are not number fields, but rather text fields where the user inputs what it was that was done. So, how can I set up these two new tables to include those fields as text fields? Or is it not possible? Will I need to set up another table for those two fields and link it back to the Activities Table? If these fields apply to a Project as a whole, put them in the project table; if they apply to each individual accomplishment (i.e. if you have Plans&Assessment for a "fuel break"), just put the text field in the new accomplishments table. John W. Vinson[MVP] |
#19
|
|||
|
|||
Need advice - how should I set this up?
"John Vinson" wrote:
If these fields apply to a Project as a whole, put them in the project table; if they apply to each individual accomplishment (i.e. if you have Plans&Assessment for a "fuel break"), just put the text field in the new accomplishments table. Well, they're just another type of accomplishment, so they apply to projects as a whole. So, I guess I will put them into the ProjectInfoTbl. But now if I do this, can I still put the fields into the Accomplishments subform? Oh, I also wanted to put an 'other' field in there too, incase something is done that doesn't fit into any of these categories. I guess I will put that field into the ProjectInfoTbl too. Thanks for the help. -justin -- I''m not an MVP. Combien de bois est-ce qu''une marmotte d''Amérique jetterait si une marmotte d''Amérique pourrait jeter le bois ? |
#20
|
|||
|
|||
Need advice - how should I set this up?
justin wrote:
"John Vinson" wrote: If these fields apply to a Project as a whole, put them in the project table; if they apply to each individual accomplishment (i.e. if you have Plans&Assessment for a "fuel break"), just put the text field in the new accomplishments table. Well, they're just another type of accomplishment, so they apply to projects as a whole. If they're another type of accomplishment, then they are NOT a quality that describes a project, and they probably should be listed as additional records in the [Accomplishments] Table. So, I guess I will put them into the ProjectInfoTbl. But now if I do this, can I still put the fields into the Accomplishments subform? Fields that you should include in the [Accomplishments] Table should be those which describe some aspect (such as cost, resources used, benefits gained, who is involved, &c.) of the specific accomplishment listed in a record in that Table. Oh, I also wanted to put an 'other' field in there too, incase something is done that doesn't fit into any of these categories. I guess I will put that field into the ProjectInfoTbl too. If I were inclined to be a gambler, I'd bet that "other" should also be a type of accomplishment; i.e., it should be the subject of another record in the [Accomplishments] Table. -- Vincent Johns Please feel free to quote anything I say here. Thanks for the help. -justin |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Advice needed: Should we upgrade MS Access 2000? And if so to what? | ship | General Discussion | 43 | November 30th, 2005 10:58 PM |
Need Database Design Advice | SMBR | Database Design | 1 | October 3rd, 2005 04:56 PM |
Need advice on choosing template... | paulb104 | New Users | 1 | June 25th, 2005 09:45 PM |
Database Corruption and advice on upsizing | Robert Harris | General Discussion | 9 | March 21st, 2005 03:50 AM |
Advice on forms | Pehr Jansson | General Discussion | 1 | January 25th, 2005 04:12 AM |