I am designing part of my database to simply the production of predictable quotations. (and have been for the last 6 months). My quotations tend to be for one product whose price varies based on the number of software licences. In each quote there will be the price for the software and the price for installation.
I will have a TblItems. In that table will be all of the items available for quotations and may include, for example, the following
Group (5 User system) Item, Description, Price, cost
In this group there will be two matching items
On my quote form i want to have a drop down field which will allow mw to simply select the number of users and then i want Access to take any item which belongs to the 'number of users selected' to another table and i will then include a quoteID etc etc.
Can anyone advise me on, the main thing, the kind of database concept on how to achieve this please? :confused:
Part of the function of my Db is to produce quotations. I specifically need one table containing line items and will use another table (update query) which will contain the 'quoted for' items. Transfer will be based on numbers of users required. I have the basic idea in mind; i will have a form with drop down to select numbers of users and then some Vb to take records from one table to the other. I can do that fine. The bit I am struggling to structure in my mind is as follows:
In a quote there will be typically three line items
1) Software 2) Installation / Configuration 3) User Training
I can easily do as described above but that relies on the main table being pre-populated with all three line items. however, I'd prefer to have the ability to have prices for daily rates, relating to installation and training, in another table so as to be able to change/update them and not have them fixed in a table.
So I think I would want to have the three line items update query across buy somehow control the list price of the services element controlled elsewhere.
Part of the function of my Db is to produce quotations. I specifically need one table containing line items and will use another table (update query) which will contain the 'quoted for' items. Transfer will be based on numbers of users required. I have the basic idea in mind; i will have a form with drop down to select numbers of users and then some Vb to take records from one table to the other. I can do that fine. The bit I am struggling to structure in my mind is as follows:
In a quote there will be typically three line items
1) Software 2) Installation / Configuration 3) User Training
I can easily do as described above but that relies on the main table being pre-populated with all three line items. however, I'd prefer to have the ability to have prices for daily rates, relating to installation and training, in another table so as to be able to change/update them and not have them fixed in a table.
So I think I would want to have the three line items update query across buy somehow control the list price of the services element controlled elsewhere.
I have to create reports from an Access database used in a commercial application. The backend uses Access but the front end does not.
The vendor does not document the data or provide any support for that. The database has over one hundred tables and thousands of fields.
I'm thinking I'll create small transactions in the application and then study the database to see what has changed. But this seems overwhelming considering how many tables and fields there are. So I'm looking for advice on how to approach this.
Hi, im currently working on a database which is for someone else. Whe it is handed over to them, they will no doubt want some changes done every so oftern eg new reports, changes to forms etc.
What is the best way to do this? The database holds a lot of data, so I dont think its feasible for them to send it to me via email everytime they need something changed!
Ive noticed a few posts here about splitting the database into a front/back end. If this was done, would they just have to send me the front end; this would probably be a smaller file ye?
If this is going to be the best way round the problem; how easy is it to split a database which is basically already made?
Hi, im currently working on a database which is for someone else. Whe it is handed over to them, they will no doubt want some changes done every so oftern eg new reports, changes to forms etc.
What is the best way to do this? The database holds a lot of data, so I dont think its feasible for them to send it to me via email everytime they need something changed!
Ive noticed a few posts here about splitting the database into a front/back end. If this was done, would they just have to send me the front end; this would probably be a smaller file ye?
If this is going to be the best way round the problem; how easy is it to split a database which is basically already made?
I want to know if anyone has taken a large database (e.g 400,000 records) and had to take a subsection of this so to reduce size. (E.g you randomly would like to take 20,000 records). I need to reduce a database size for a test situation but would like to know what I should consider when reducing the size in this way.
Do I take the base database structure – table organisation with fields linkages etc and load data in?
I have some help in this task but would like to know of any advice that could be provided.
Is there any way to keep track of a database structure in access? For instance, which query relates to which report? Sometimes I create queries that are no longer needed but if there are a lot (which there are!) it can be easy to delete one that's needed.
I created a database to track tardies and absences of my employees. I would like to be able to sum the number of absences and tardies for each person per month and graph it.
Per our attendance policy, 6 tardies = 1 absence. I need to take the total number of tardies that month/6 and add to the total absences that month to equal the total attendance for the month.
I need help. Can you please view my database and give me some ideas?
I am designing an application that tracks information on Choir membership and sheet music that we have on file. I am starting with a database of church members. There are four different choirs and choirs share some members. Some members of some of the choirs are also not members of our church so I will have to place non members in the member table. I am new to database design and would like the collective wisdom of this list to tell me of any problems I may encounter before I start doing any detail work.
What is the best way to deal with someone who is a member of more than one choir and may belong to a different section in this other choir (Tenor in one and Bass in another). An individual may also hold different offices in various choirs.
The table structure I have is as follows
CHURCH MEMBERSHIP DB: MemberId Autonumber (pk) FirstName, Text MiddleName, Text LastName, Text DateJoined, Date Phone, Text Address, Text City , Text Zip, Text EmailAddress BirthDate, Date Member, Boolean
CHOIR MEMBERSHIP DB (How do I efficiently track someone in > 1 choirs) MemberId, FK ChoirId, FK FolderNo RobeNo Section ChoirOfficeId, Fk
CHOIRS DB (This lists the various choirs in the Church) ChoirId, pk ChoirName, Text DirectorId, FK (Pointing to Member DB, Person may not be member of any Choir)
MUSIC DB CatalogId, PK Title Composer Arranger Type (Single Copy/octavo or book/collection) PublisherId, FK PublisherNumber VoicingId, FK (From table with possible voicing) NumCopies UsageId, FK (Where in the service is it appropriate Location, Text (Where in the filing system, or off site) ClassificationId, FK (List of classification/genre in table so can update)
PUBLISHER DB PublisherId, PK PublisherName PublisherAddress PublisherPhone PublisherWeb PublisherContact
MUSIC CLASSIFICATION DB ClassificationId, PK Classification, Text (Christmas, Easter, general anthem etc)
To be able to track performances and plan services and performances I have the following table.
PERFORMANCE DB (This is to keep track of and plan the regular service) PerformanceId, PK Pdate, date (Date of Past/Planned performance. Possibly more than one per day) ServiceTypeId, FK (From table of types of performances – morning service, evening, etc) Location Speaker Pianist Organist Introit Invocation Anthem Meditation Benediction (etc)
I would also like to be able to prepare mailing labels for the various choirs as well as the general membership from this DB. My primary focus will be on the music. I would like to have an efficient music DB that I may find out what music I do have and when I last performed them, what options for performance (usage and classification)
I am trying to figure out how to store data into a database to be use later in a web app. So I have a shirt and it can come in four different colors. What would be the best way to enter this into the database. I'll have shirts, jackets and accessories which I have give each their own table. The shirt one is giving me trouble though, I just don't know how to organize it.
Hi, I would like to get your advice on my table setup and relationships for this payroll project. The company is an engineering company with Projects (or construction sites) around the world.
The 'Candidates' are current or potential employees and contractors. There are three main pay categories:
1.Shift-workers All shift workers doing a particular job on a particular project are paid the same rates e.g. all welders on a particular project or site in England are paid the same as each other. For that reason I want to link the pay rates with the job description for these workers. This avoides creating 50 records for 50 welders on the site in England to say that they make £10 an hour normal time (or whatever it is) etc.
2. Contract Contract workers usually get paid a flat rate per hour. As these are negociated on an individual basis I would need to have this information linked to each individuals job (M_CandidateJobDetails).
3. Salary Again this information needs to be input for each individuals job.
For the contract and salary people the pay frequency can vary (weekly, bi-weekly or monthly). So can the currency they are paid in. I haven't got as far as the currency issue yet.
The reason for the one-to-many relationship between M_JobClassifaction and M_CandidateJobDetails is that many candidates can have the same type of job e.g. there can be many employees that in the job classifaction of 'Electrician'. For many of the jobs at managerial level e.g. 'site manager' there will only be one.
I will have a table with the hours worked by each person per week. I can use this for those on shift work or contract to calculate what they will be paid.
One of the main reasons for this database is so that the company can print reports to see what is paid out in payroll for each site and in total (in euros). These will be gross figures and I don't need to take expenses, vacations, bonuses or taxes into account. They other thing we will need to be able to do is assign candidates to vacant positions and change them from one position to another - possibly between different projects.
So basically does anyone have any comments on the relationships, normalisation or anything else. Is this the best way to do it?
I'm doing some changes to a database in work, but the person who created it doesnt work there anymore and so nobody knows anything about it. The database has been split into a front and back end, which is fine, but there appears to be 3 seperate databases linked to the main one, each with a .mde file for security. Depending on which department you're in, you access your database. Any information being added is updated in the main front end database. Does anybody know how that will be linked? I'm just probably going to have problems when encorporating my changes.
Hello, I am looking for someone's professional opinion to help me clear up some unresolved technical issues in my mind... =P Ok, I have a contact management database that would seem really straightforward to me except for the fact that I am dealing with 2 primary entities. In this I mean I have an Individual table and Organization table. These two tables have primarily the same field data, such as both having address data, phone (contact info) data. There are some unique fields to one entity that aren't contained in the other entity though, and visa versa. One important issue is that 0, 1, or more individuals can be related to an Organization. Therefore I now have linking tables for IndividualOrganization, as well as linking tables for Phone and Address data. My primary complication is that since both Individuals and Organizations have address and phone data, the respective linking tables for them contain: an addressID/phoneID key, for the appropriate linking table, with an OrganizationID key and an IndividualID key in each table. So, the way I am thinking is that if the record pertains to an Individual, the appropriate ID will be in IndividualID and the OrganizationID will just be 0, or empty. This brings up issues with primary keys being blank. I am wondering if there is a better way to do this that I am overlooking or if I am in fact on the right track? I have contemplated combining the Organization and Individual tables into one but that really doesn't seem like the best solution. If anybody has any ideas then I would GREATLY appreciate it. I had a working database the other day but now I am separating the phone and address info out of the primary tables and have really got a mess on my hands. =P If anybody would like to look at my database structure I'd be more than happy to post the back_end and the front_end for you to give me your honest opinion about any trouble areas. Thanks BIG TIME in advance to any nice souls willing to help out a struggling programmer who doesn't have any close support on this one as I am working alone, :rolleyes: Dana S.
Booking - BookingID Course - CourseID Company - CompanyID Materials Materials_on_course (had to have this in order to avoid many-to-many.) Employee - EmployeeID Employee_runs_course (had to have this in order to avoid many-to-many.)
I'm stuck with the Course and employee thing. Each employee has an expertise or two, and therefore each course has an expertise needed to run it (a specialist if you like).. so the PK in 'course table' is Course ID, you cannot have two PKs in one, so would it be right to say that the 'expertiseID' would have to go in 'Employee_runs_course' ?.. what would i do then? place 'expertise ID' as an FK in both employee and course tables?
Extra info:
Clients (tblCompany) can book one or many courses A course can have one or many bookings made for it A booking has one or many employees/courses An employee can work on many bookings (obv if available) Each employee has one or two expertise (usually only one) and therefore a course has on expertise attached to it.
__
If you have a better way of designing it, shoot! Attachment: ERD (kinda) of first draft.
I am building a database of in-car audio systems. Stored in this are simple things like vehicle information, audio brand and other general information. The main information I need to store includes details about speakers (position, quantity, material, range, size etc.) and amplifiers (power output, no. of channels etc.). Sounds simple I hope.
I have been thinking about this extensively and have come up with two solutions, each with its own pros and cons. My primary concern here is how the speaker and amplifier information is stored:
1) Tables specific to car regions (e.g. Rear Speakers, Front Speaker, Surround Speakers) have the fields 'Range', 'Material', Size, etc. Range and material can read their values from other look-up tables no probs. These would be linked to the main table via it's primary key in a 1-M relationship. -Pros: Ease of construction and general handling of data Flexibilty/expandability (in terms of speaker quantity) -Cons: When it comes to data entry the form would need to be continuous and continuous forms I have found to be a pain in terms of referring to individual records! I want some of these controls to conrol a diagram for my report (and input form) - such that they show/hide speaker pictures on a car diagram. Also, I have not yet figured out how to validate a continuous form in this situation or delete records from it either (should the user makes an error).
2) Again, tables specific to car regions but this time with a field for each speaker range (mid-range, tweeter, woofer, etc.) and it's associated data, tied to the main table via the main table ID in 1:M relationships. -Pros: Easy to manipulate form/report properties because every speaker has its own field Easier to remove erroneous data (I imagine) -Cons: More complex construction (and less efficient) - e.g. material occurs more than once for each record so to look up material form a central pool requires an intermediate table Many many more fields! Non-expandable in terms of speaker quantity
Similar principals can be applied to amplifiers so I haven't mentioned those.
I was going to say before I screw it up, but that would have made the title too long.
I've read some forum history and done some searches and can't see that a similar query has come up previously - but if anyone can point me at previous relevant threads then that would be much appreciated. I've looked at some of the design theory threads, but am not really sure whether I've applied some of the good stuff in there effectively - and have put this query here as it's specific to my database rather than a 'general principles' thing.
I am hoping that some kind person/people might be able to pick holes in my planned database revamp as I may not have seen some of the pitfalls - thank you.
Background: I am the first and sole employee of a grant-making trust and set up our (still relatively small) database early on - wish I could have waited, but before my database everything was paper-based and impossible to manage. The data is all on the database, but an exponential growth in number of enquiries/applications over the last year means that it can't be easily manipulated in a way that meets our needs because of my short-sighted (OK, poor owing to inexperience in job) initial design in some areas.
Database: What it's supposed to do: In brief, the way our organisation works is that we get a phone call or a letter or sometimes an entire application from a charity or community group, decide what to do with it and have to manage the funding contract (regular reviews, grant instalments) if the application is successful.
I think existing data is reasonably normalised (certainly at least equivalent to normalisation in the structure below) so migration shouldn't be a problem, but if anyone spots any normalisation or naming convention issues then please do point them out - I'm an Access amateur, but would like to get it as right as I can (this time). Small letters indicate linked tables, numbers indicate 'footnotes'.
(a) tblProjEvent PEvID (primary key) PEvDate ProjName ProjEvent (g) ProjEvDesc - additional detail - e.g. who involved, topic if not obvious from event field. ProjEvActWho - who is responsible if future action ProjEvActDue - due date ProjEvActComp - checkbox ProjEvActCompDate ProjEvNote (NB not to duplicate description - more for 'additional notes arising from completed action' or sensitivities that may need to be considered and kept separate from regular reporting)
(b) tblOrganisation Details not listed for brevity, but split one field per line of address/detail, org name as primary key - existing table can be migrated as is (2). Includes suppliers, networking orgs. (f)
(c) tblProjSourceLup How they heard about us - list of sources for speed/consistency of data entry.
(d) tblProjStatusLup What it says on the tin - where we're at right now with a project. History/status changes recorded in tblProjAction.
(e) tblProjReasonDecline List of common reasons for speed/consistency of data entry
(f) tblOrgContacts OrgContact ID (primary key) Names/personal details of organisational contacts, split one field per item (firstname, lastname, jobtitle, etc).
(g) tblProjEventLup Letter, Funding contract, review meeting, report, telecon, Board review, etc. May be a future action.
Accounts functions: Payments in/out linked to organisation with a lookup table for account types (in, out, grant, donation, expenses etc etc). Works fine and can be migrated as is (2)
The current arrangement of relationships has the organisation as the focus - I'm looking to make the project the focus, which seems to make sense as each project is unique - whereas we may get several project applications from the same organisation - and the existing structure makes it impossible to sort these out :o.
Footnotes
1) Vast number of applications that fall into the "arrive, get read, get binned" category make this duplication worthwhile - most applications won't make it into the Project Event table. Apart from the "Greetings in the name of the Lord"/419 e-mails, they do all need recording somehow so we can spot any trends and correct misinformation - save hard-working fundraisers wasting their time*.
2) Of course data validation will be necessary, but in most tables we're talking hundreds or thousands of records only, not tens of thousands so should not be that onerous. Especially as I've been the only person using the database, so there are hopefully not too many inconsistencies!
This post is too long already, but if I've been uselessly unclear in explaining anything or anyone wants any more before they want to comment on efficacy of structure please let me know. All feedback appreciated (as I said, I work alone, so really looking for idea-bouncing to check I can see the wood as well as the trees as much as anything - thanks).
*As charity is always a sensitive area and some of you may be involved with voluntary work, an OT comment: 'No response' might seem rude - but if an organisation is -clearly- excluded by the criteria on our website, or that very same person (or a large charity who should be able to manage its information effectively) has previously been told that they are ineligible by reason of their location, size or type then they have had their response already. I could spend all day every day writing 'No' letters - I'd rather be doing something more positive with my time (like checking out/meeting with organisations that are potentially eligible so they get their answer - and in some cases money ASAP). Not R-ing TFM (aka grant guidelines) apparently applies to fundraisers as much as any other profession :rolleyes:
Access 2000: How can I populate a two field table (1. Table Name 2. Field Name) with the name of ever field within every table in my database using VBA code?
I would like to build a database to keep track of tardies and absences in my dept (~70 employees).
I need Date, Name, tardy or absent,
My current table:
TblEmployees EmployeeID PK Last Name First Name Team
TblEvent EventID PK Event (Tardy or absent)
TblAttendance Date EmployeeID EventID
Is this a good structure? I need to be able to run a query that will sum the total number of tardies and divide by 6. That number will then be added to the total # of tardies. The query needs to only show the values over the last 6 months. Any help is appreciated.
Lets say u have a database that keeps track of all items sold and their respective prices. So u have a items table that keeps the product information and price. Then these items are displayed on invoice kept in a invoice table linked with a foreign key and a one to many relationship.
My question is lets say the price of an item should change....will the invoice table of old invoices display the new price or old price. Is this where the referential integrity comes to play ? Should u select it when doing the relationship ticking the cascade update related fields and cascade deleted records boxes respectively or not ?
