This is what our form looks like:
InstructorsID CourseCode Section Surname FirstName MiddleName Date1 Date2 Date3 Date4 Date5 Date6 Date7 Date8 Date9 TotalAbsent Present EquivalentGrade
Alex Comp100 DCIT-1b Bancil Lenrick Malabanan Check Check Check Check Uncheck Uncheck Check Uncheck Check 3 6 83
The columns that has a name "DATE" are checkboxes and it represent the inputted value in the text box. We wanted to save the header of a datagridview in the database to the new fields that we added to the database.
And this is what our database looks like :
InstructorsID CourseCode Section Surname FirstName MiddleName DateA Date1 DateB Date2 DateC Date3 DateD Date4 DateE Date5 DateF Date6 DateG Date7 DateH Date8 DateI Date9 TotalAbsent Present EquivalentGrade
Alex Comp100 DCIT-1b Bancil Lenrick Malabanan 06/02/14 Check 06/03/14 Check 06/04/14 Check 06/05/14 Check 06/06/14 Uncheck 06/07/14 Uncheck 06/08/14 Check 06/09/14 Uncheck 06/10/14 Check 3 6 83
We want this to happen to our database. When you pressed the button save, the header will be saved in the database. The case is that when you pressed the save button and you look at your database you can see a new added row in the database . Can anyone please help us ! we've been trying to figure out what to do but until now we don't get to solved it!
It is fundamentally wrong to just "save from grid to database". Database is comprised of tables, relations between those tables, stored procedures, views etc. The data in the database must follow the atomicity principle. This basically means, that every transaction in database must be treated as a complete whole. This means, that if you want to do something in your database, that involves multiple inserts/deletes/updates this represents a transaction and if one of e.g. inserts fails, everything is revoked (this is called "database rollback"). If everything goes well, the database then applies the desired changes to the data via so-called "database commit".
The other, very important thing you must always keep in mind is that every database field should have only one value. So if you are storing the name of a person, you actually need two database fields: FirstName and LastName. If you want to complicate our life even further you obviously have to include MiddleName, MaidenLastName etc.
How is this relevant?
Gridviews are used to present data. They serve as a window into your data and usually make data useful. Sometimes people also populate gridviews in such way, that they create 1 column (let's call it Name) and then show FirstName+" "+LastName in that column. There is nothing wrong with this, but in your case, this presents a problem because you can create orange juce from an orange but cannot recreate the orange back from juice..
Datagridview is a WinForms control and is, as such able to present data from various datasources. Which database/datasource are you using?
I'm afraid you have provided insufficient information for my answer to be more thorough. I can however say,:
that your problem is probably more specific and you will have to provide additional details.
you shouldnt change the database schema based on user input
if you really need this kind of behavior, you will need to familiarize yourself with your database's DML (data manipulation language - for manipulating data) and DDL (data definition language - for changing schema, altering other schema-related issues).
Feel free to expand your question or to ask further.
Related
I'm an intern student at a company that does both wiring and aircon services. The job that they gave me was to make a database for them. I don't have any experience in anything related to databases.
So, I started to look up videos and stuff to at least learn a bit about databases and made something that works and I made it after 1.5 months of learning.
in the database that I created,
I have 1 table (CustomerDetailsT):
CustomerID (pk)
CustomerName
PhoneNumber
Address
Aircond (type and model of ac,ex: WM daikin 1.0HP)
AcDetails (what has been done for the ac.)
Others (yes/no) (Wiring, installing a fan and so on)
WhatHasBeenDone (shows what has been done for others)
Then 3 queries (CustomerOthersDetailsQ, CustomerAcDetailsQ, CustomerDetailsQ).CustomerAcDetailsQ has CustomerName, PhoneNumber, Address, Aircond and AcDetails. CustomerOthersDetailsQ has CustomerName, PhoneNumber, Address, Others, and WhatHasBeenDone.CustomerDetailsQ has CustomerID, CustomerName, PhoneNumber and Address
And 1 form with 3 subforms.
it's a search form, which would search for customers as we're typing in their name/phone number and it will show what has been done for the customer.
With this, I have created what the company wants, but now they want to add dates. Dates which would show when we have done something for a customer. Dates for Aircond and the Others stuff.
I've tried with what I know and it didn't work. tried searching it on youtube and google, but still couldn't find it.
how can I go about doing this?. I have tried having separate tables for each service, but it became a hassle when I wanted to create a new customer. . I hope I could some help, I could send pictures if someone needs them.
[1]: https://i.stack.imgur.com/mtrmC.png [The Customer search form] [1]: https://i.stack.imgur.com/A3Y9d.png [example of a customer that has ac installation] [1]: https://i.stack.imgur.com/dsGL5.png [example of a customer that has both ac and wiring done]
Acknowledging the question is too broad, here is some guidance. One of the nice things about Access is that each database is a single file. First protect your work by finding that file and make two copies. Make a backup and a play around version. Only mess with the play around version.
Your question indicates you are still learning Table Normalization and 1 to many relationships. Both of these topics are general to all databases, so you don't have to restrict yourself to just Access when looking for guides and Youtube videos.
Part of normalization is putting separate entities into their own tables. Also, in Access there is a big payoff for using the Relationship Tool, so here is a rather lame example of normalization:
Make sure to select the checkboxes when setting up relationships.
WhatHasbeenDone should also have WhatHasbeenDoneDate. I've wrapped AC and Other as Unit because later it will be easier than having two WhatHasBeenDone tables(AC)(Other).
Now imagine someone taking the customer request call. They just want to see a form to enter the customer details, request, unit-type, etc. They don't want to see those tables. Even with training entering data in the tables is error prone. The person fulfilling the request just wants to enter what they did and when. That's how you start to figure out what your final Data entry forms will look like.
Since we normalized the tables and used the relationships tool, the payoff is Access can give us an assortment of working starter forms. Select Each Table and then hit Create and then hit Form. Choose your Favorites and start playing around from there. While playing, keep in mind that Access will not let you add an item on the many side of a relationship unless there is an item on the 1 side.
For example I selected the customers table and hit create form:
Access uses a concept of form and subform based on separate but related tables. So, to get a form that shows what has been done for each customer I created a form for the What has been done table, and dragged it onto the customers form:
Unless an ID is also being used as a part number or something there is probably no reason for the person entering data to see it. So I removed the texboxes bound to ID's. Except for UnitTypeID, where I replaced the textbox with a combobox that displays the userfriendly UnitDescription. The ID's are still part of the form recordsources, Access is still adding new IDs and using those IDs to put the appropriate data in the right tables.
Oh, didn't we need dates (went back and added a date to the table, and adjusted the subform accordingly). Also changed the subform format from single record to continuous records to show multiple dates:
In conclusion and in my opinion your final forms will use VBA behind the scenes to insert data from the forms into the tables. This is because either you will want to rapidly insert multiple records or How the end users think about the data will not match the default forms and subforms approach Access depends upon to figure out how to insert the data. However, the default approach is fast and I always use it for version 1 of my Access Databases.
P.S. For simplicity I avoided including any Many to Many relationships
Wondering if someone could assist with the best way to handle storing "checked" items in a MSSQL database.
On my form, i have a list of fields (name, address ect) and then a listbox the user can check for e.g. favourite colors.
In my database I would have a table for user details (tbl_userdetails - [UserID, Address...]) and a table for colors (tbl_colors, [ColorID, ColorName, ColorCode]). I would also need a table for user colors (tbl_userColors - [userID, ColorID])Theses would be linked via a "userID"
Normally, to save the user details, I have a sql string "UPDATE tbl_userdetails SET... WHERE userID = #userID". What is the best way to save the changed checked items into the next table?
My thoughts are:
Delete all the colors for UserID in the tbl_userColors and then loop the checked items into a "INSERT" statment.
Loop though each item that exists in the list create a datatable and then "merge" the data (on match, insert. on not matched delete)
Any other thoughts? What is the best way to build the INSERT statment?
Cheers
The DELETE and INSERT strategy works well as long as nothing is tied to those records. If you ever have any tables that reference tbl_userColors on the "one" side of the relationship, then you will have headaches.
The MERGE strategy is decent, usually. One possibly unfortunate consequence would be that a MISSING record is the same as a FALSE record. For instance, you Have your list of colors, {red, green, blue}, and your users are making their selections. Six months later you get crazy and add orange. Now you have no idea who didn't select orange vs. those that simply weren't presented with orange as an option.
A third option is to place an Enabled BIT field on the tbl_userColors table. This allows you to determine if a user was presented with a color option and they declined it vs. if the user never saw a particular color option.
Speaking of Enabled BITs. Your tbl_colors table should really have an Enabled BIT as well - or some other mechanism of removing a color from the UI without removing its database record. You realize at some point you no longer want to offer blue to your users, but you also don't want to loose the historical data.
And a small aside: Your tables names are horrific. You should really consider dropping the Hungarian notation. I'm a big fan of camel-case table names: Users, Colors, and UserColors.
Simple really. When an item is checked it returns a boolean. Whenever you get ready to save to the database you just want to loop through the colors and if it is checked (AKA is check is true) then you add it to a list that you can later loop through to save all of the values.
I'm trying to think of the easiest way for non-tech users to dump info into a database, without coding my own web application.
Essentially, they are recording subjective phone grading scores for employees.
I linked an Access form to our MS SQL Server database. The only validation I want it -- I want one field, 'employee' - to be validated against a list of employees from say table.employee on SQL Server.
Once the form is submitted it will be written to table.scorecard -- or what have you.
Is this possible in Access? Their standard validation rules don't seem to cover this. Also, is there simply a better way to accomplish this task in general? Thanks
There are two ways to solve this problem.
The simplest is to use a combobox field for your employee information. Use the employee table as the list data source for the combobox and then set the LimitToList property to true. This assumes that you have setup linked table connections for both your employee table and your 'scores' table.
The second solution is to create a foreign key between the employeeId (or whatever the key field is) in the scores table and the employee table on the SQL side. If someone tries to insert an invalid employee, you will get an insert error. Unfortunately, SQL errors tend to be very confusing to most Access users.
If you want to be very through, you could implement both solutions, this would prevent someone going straight to the linked tables and putting in bad data.
I just realized that I am assuming that you are doing proper relational design where the 'scores' table would contain the employeeId rather than a full name. The idea on the form is to have the combobox display the name, but insert the employeeid field.
Is there an existing implementation or even a name for a type of database which allows multiple points of view? What I mean is for instance if one user changes an article's title then the change will only be visible to that particular user and everyone else will see the original title. If several users change it to the same new title then the new title becomes the 'master view', or the 'unfiltered view' of the database, initiated either by the database or from the application.
I'm coding in C# and am familiar with SQL and starting with MongoDB but the question is about the concept and whether abstractions, implementations, or design patterns of it exist.
If your "point of views" are completely separated, you could just use a new database for each user.
From your question it seems you want to have some degree of interconnectedness. Perhaps articles created by any user should be visible to everyone? Is it only changes after creation that should be private? How about updates from the original author?
I think you just need to specify the behavior you need, and design a database that can handle that.
One solution could be to use both the (article) id and the user id as the key for your tables. That way you can completely replace content for specific users. Let's say you want to find article 123, as seen by user 456, or if that user doesn't haven't edited it, as seen by user 789, or if that user haven't edited it, just pick any version:
SELECT * FROM articles WHERE id = 123 ORDER BY user_id = 456 DESC, user_id = 789 DESC LIMIT 1
For the first time, I am developing in an environment in which there is a central repository for a number of different industry standard reference data tables and many different customers who need to select records from these industry standard reference data tables to fill in foreign key information for their customer specific records.
Because these industry standard reference files are utilized by all customers, I want to reserve Create/Update/Delete access to these records for global product administrators. However, I would like to implement a (semi-)automated interface by which specific customers could request record additions, deletions or modifications to any of the industry standard reference files that are shared among all customers.
I know I need something like a "data change request" table specifying:
user id,
user request datetime,
request type (insert, modify, delete),
a user entered text explanation of the change request,
the user request's current status (pending, declined, completed),
admin resolution datetime,
admin id,
an admin entered text description of the resolution,
etc.
What I can't figure out is how to elegantly handle the fact that these data change requests could apply to dozens of different tables with differing table column definitions. I would like to give the customer users making these data change requests a convenient way to enter their proposed record additions/modifications directly into CRUD screens that look very much like the reference table CRUD screens they don't have write/delete permissions for (with an additional text explanation and perhaps request priority field). I would also like to give the global admins a tool that allows them to view all the outstanding data change requests for the users they oversee sorted by date requested or user/date requested. Upon selecting a data change request record off the list, the admin would be directed to another CRUD screen that would be populated with the fields the customer users requested for the new/modified industry standard reference table record along with customer's text explanation, the request status and the text resolution explanation field. At this point the admin could accept/edit/reject the requested change and if accepted the affected industry standard reference file would be automatically updated with the appropriate fields and the data change request record's status, text resolution explanation and resolution datetime would all also be appropriately updated.
However, I want to keep the actual production reference tables as simple as possible and free from these extraneous and typically null customer change request fields. I'd also like the data change request file to aggregate all data change requests across all the reference tables yet somehow "point to" the specific reference table and primary key in question for modification & deletion requests or the specific reference table and associated customer user entered field values in question for record creation requests.
Does anybody have any ideas of how to design something like this effectively? Is there a cleaner, simpler way I am missing?
Option 1
If preserving the base tables is important then I would create a "change details" table as a child to your change request table. I'm envisioning something like
ChangeID
TableName
TableKeyValue
FieldName
ProposedValue
Add/Change/Delete Indicator
So you'd have a row in this table for every proposed field change. The challenge in this scenario is maintaining the mapping of TableName and FieldName values to the actual tables and fields. If your database structure if fairly static then this may not be an issue.
Option 2
Add a ChangeID field to each of your base tables. When a change is proposed add a record to the base table with the ChangeID populated. So as an example if you have a Company table, for a single company you could have multiple records:
CompanyCode ChangeID CompanyName CompanyAddress
----------- -------- ----------- --------------
COMP1 My Company Boston <-- The "live" record
COMP1 1 New Name Boston <-- A proposed change
When the admin commits the change the existing live record is deleted or archived and the ChangeID value is removed from the proposed record making it the live record. It may be a little tricky to handle proposed deletions with this option. This option also has the potential for impacting performance of selecting live data for normal usage. However it does save you the hassle of maintaining a list of table names and field names somewhere in your code.
I'm sure others will have some opinions!