I am making a maintenance DB in Access. I have this form which shows the pending routines from a table:
There is a detail table for the parts of the machine on which the routine needs to be executed
I want that whenever I press the execute button on the form, one record gets added for the work orders table, and one record for each record the maintenance_detail table which belongs to the record in the maintenance table gets added to the work_orders_detail table. What would be an efficient way to do this?
Work orders and work orders detail tables:
Related
I have 3 tables:
Customers Table
Transactions Table
Delivery Table
In the customers tables every customer has a delivery rate (based on their location).
What I am trying to accomplish is when I add an order to the transactions table, if the checkbox is checked it should automatically add new a record in the Delivery Table filling out the customerID, & Date, based on current transaction name & date & DeliveryCharge based on the delivery rate this customer has.
How do I accomplish that? Please Help!
NOTE: I am not sure if by making a separate Delivery Table like I did is the way to go in general. If you have a different/better way to add optional shipping charge with query, etc. Please let me know.
First, a discussion about your table structure. Your Transactions table is using CustomerName instead of CustomerID. That will give you problems. In this case, it doesn't appear there is much difference between the Transactions and Delivery tables. Therefore I would recommend combining them. The only reason I would not is if you intend to split transactions into multiple deliveries. Finally, your Transactions table should not include the total price. Make another table like TransactionDetails that tracks the price of each product purchased and associates it with a single transaction number.
As for the rest of your question, you have a pretty broad approach question so I will give you a broad answer. One way you can do this is to use a form. VBA is absolutely capable of running the SQL queries you need, storing the values in variables, and then reusing them in an INSERT query.
I would recommend implementing it with a form that gets your user input and has a button to click that runs the required queries. Without more specific coding, I'm afraid you're not going to get much more feedback.
I have one table called ClientInfo that stores a client's personal information and another table called EmergencyContactInfo that stores their emergency contact information. Right now I have an update trigger on my ClientInfo table that inserts a single record into a third table called ClientLog if any of their personal information changes. I would also like to create a ClientLog record if the client's emergency contact information changes.
The problem is that the user can change both a client's personal information and their emergency contact information with a single save from my webpage. If I put an update trigger on my EmergencyContact table, then both my triggers will fire and the ClientLog table will insert two new records when I only want one.
From what I understand there is no such thing as an update trigger that spans across multiple tables. What is an alternative approach I could take that would insert a single record when both the client's personal information AND their emergency contact information changes?
Your understanding is correct that a trigger cannot span multiple tables.
There is also no such thing as preventing a trigger from firing.
What you CAN do is include logic in your trigger that prevents it from doing anything if certain conditions are true.
Now I don't know what you're writing to your log table, and what logic you would want to enforce, but an example would be, when the trigger fires, if there is already a log entry (row in the Log Table) for the same Client in the past x hours, then simply don't insert a new row in the log table.
You can even handle multiple row insert/updates with an OUTER JOIN to the log table, or a WHERE NOT EXISTS() clause.
But basically what I'm saying is, let both triggers fire, and in both triggers, check to see if some condition is true/false before writing to the Log Table. Otherwise, do nothing.
You're making this unnecessarily difficult and error prone.
If each data table has a separate log table and it's own trigger, you can ignore the entire issue and just let them work as they're supposed to.
If you want to view the log info together, you can use a JOIN on the two tables when you display the data.
I am working on banking application, I want to add a feature of maker,checker and authorize for every record in a table. I am explaining in below details
Suppose I have one table called invmast table. There are 3 users one is maker, 2nd one is checker and last one is authorize. So when maker user creates a transaction in database then this record is not live (means this record can not be available in invmast table). Once checker checked the record and authorizer authorized the record the record will go live ( means this record will insert in invmast table ). Same thing is applicable for update and delete also. So I want a table structure how to achieve this in real time. Please advice if any.
I am using vb.net and sql server 2008
Reads like a homework assignment.....
Lots of ways to solve this, here's a common design pattern:
Have an invmast_draft table that is identical to invmast but has an additional status column in the table. Apps need to be aware of this table, status column and what its values mean. In your case, it can have at least 3 values - draft, checked, authorized. Makers first create a transaction in this table. Once maker is done, the row is committed with the value "draft" in the status column. Checker then knows there's a new row to check and does his job. When done, row is updated with status set to checked. Authorizer does her thing. When authorizer updates the status as "authorized" you can then copy or move the row to the final invmast table rightaway. Alternatively, you can have a process that wakes up periodically to copy/move batches of rows. All depends on your business requirements. All kinds of optimizations can be performed here but you get the general idea.
In our multi-user Access environment, sometimes it is necessary to perform different actions on a group of records. In the Orders table, for example, a user may want to delete a group of orders, or to print out a group of records, etc. To accomplish this, in the Orders table, I created a boolean field called aSelect (the "a" is to avoid the "Select" SQL reserved keyword). On the Orders form, users can check off the orders which they want to process by clicking the checkbox for the aSelect field and then click "print", "delete", or whatever other operation. The code behind the form then says to process the operation on all Orders WHERE ASELECT=TRUE
The problem is that, (while it hasn't happened yet), the aSelect checkbox is bound to the underlying field in the table, and two users can change aSelect at the same time. So, suppose user A selects two records to delete, but before he hits the delete button, another user attempting to print a 100 records selects 100 records. The result will be that all 100 records will be deleted--not the intended result.
Any solutions or alternatives? This scenario plays out numerous times throughout the database. The Orders table is just one example.
Thanks,
Create a table with a username/userid column and an OrderID column.
When the user makes a selection, add a record to this table with the OrderID and username, then when running your query just join this selection table or use an IN() clause and filter by username.
Voila - user specific selections, which could be improved/expanded upon but this is my basic offering.
I'm curious on how some other people have handled this.
Imagine a system that simply has Products, Purchase Orders, and Purchase Order Lines. Purchase Orders are the parent in a parent-child relationship to Purchase Order Lines. Purchase Order Lines, reference a single Product.
This works happily until you delete a Product that is referenced by a Purchase Order Line. Suddenly, the Line knows its selling 30 of something...but it doesn't know what.
What's a good way to anticipate the deletion of a referenced piece of data like this? I suppose you could just disallow a product to be deleted if any Purchase Order Lines reference it but that sounds...clunky. I imagine its likely that you would keep the Purchase Order in the database for years, essentially welding the product you want to delete into your database.
The parent entity should NEVER be deleted or the dependent rows cease to make sense, unless you delete them too. While it is "clunky" to display old records to users as valid selections, it is not clunky to have your database continue to make sense.
To address the clunkiness in the UI, some people create an Inactive column that is set to True when an item is no longer active, so that it can be kept out of dropdown lists in the user interface.
If the value is used in a display field (e.g. a readonly field) the inactive value can be styled in a different way (e.g. strike-through) to reflect its no-longer-active status.
I have StartDate and ExpiryDate columns in all entity tables where the entity can become inactive or where the entity will become active at some point in the future (e.g. a promotional discount).
Enforce referential integrity. This basically means creating foreign keys between the tables and making sure that nothing "disappears"
You can also use this to cause referenced items to be deleted when the parent is deleted (cascading deletes).
For example you can create a SQL Server table in such a way that if a PurchaseOrder is deleted it's child PurchaseOrderLines are also deleted.
Here is a good article that goes into that.
It doesn't seem clunky to keep this data (to me at least). If you remove it then your purchase order no longer has the meaning that it did when you created it, which is a bad thing. If you are worried about having old data in there you can always create an archive or warehouse database that contains stuff over a year old or something...
For data like this where parts of it have to be kept for an unknown amount of time while other parts will not, you need to take a different approach.
Your Purchase Order Lines (POL) table needs to have all of the columns that the product table has. When a line item is added to the purchase order, copy all of product data into the POL. This includes the name, price, etc. If the product has options, then you'll have to create a corresponding PurchaseOrderLineOptions table.
This is the only real way of insuring that you can recreate the purchase order on demand at any point. It also means that someone can change the pricing, name, description, and other information about the product at anytime without impacting previous orders.
Yes, you end up with a LOT of duplicate information in your line item table..; but that's okay.
For kicks, you might keep the product id in the POL table for referencing back, but you cannot depend on the product table to have any bearing on the paid for product...