my questions targets at editable JTables (using TableCellEditor).
Some tools (like SQLDeveloper) allow the user to edit multiple records, create new one or delete existing records. The table shows the modified records, but the modifications are local only, until the user clicks a "save" button (or "commit" in case of SQLDeveloper). The user can also revert all his changes.
What is the best way to implement this behaviour in a Swing application with a JTable?
I don't think, that a tool like SQLDeveloper creates a copy of records listed in the table. My first idea was to create a TableModel that wraps another TableModels (this allows me to use an arbitrary implementation of TableModel) and stores only the values of the modified cells. This works fine, when the number of rows does not change. But how to handle inserting or removing rows?
Thanks in advance for any hints.
Markus
Inside your TableModel your can register a TableModelListener with the parent TableModel and process the events for insertion or deletion accordingly also within your model.
Related
Friends,
I have a table that contains data on the two parents of students at a college. Each parent will be sent an email with a link to a web page that will display the parent data that we currently have on record (names, email addresses, mailing addresses, employment information, etc.), and will be able to edit the data in order to update our records.
Since each parent will receive a link to the same data, and will be able to update the same fields, there is the potential for both parents opening the data at the same time, and then one parent submitting changes, then the other submitting changes which would overwrite those submitted by the first parent.
In order to avoid this, I have thought of using the method I've read about in which a timestamp field exists in the parent data record, and that timestamp is used as a hidden field on the form. Then, if both parents load the form, they'll both have the same timestamp stored in the form. When the first parent submits her/his updates, though, the timestamp field will update, and when the form is submitted by the second parent, the timestamp from her/his form will not be the same as the timestamp in the table, and the program (a Perl CGI) would alert the 2nd parent to this fact, and tell them to reload the form or risk overwriting the data submitted by the first parent.
That will work, but the person for whom I'm creating this form has asked if, instead, there's a way to lock the record in the table as soon as the first parent loads the form, and if the second parent tries to load the form while the lock exists, the form will tell them to wait until later (or words to that effect). The lock would be in place either until the form is submitted by parent one, or until one hour (or some specific period of time) has passed. Is this even do-able? I've been Googling, and don't see specific examples of this having been done.
Is there some better solution to this issue of needing to prevent two people from updating the same record, and the second submitter overwriting data submitted by the first.
Thanks for any help you can provide!
Doug
*******to address the comment by "inspiredcoder," here are some more details about what I'm concerned with here:
What I'm trying to avoid having happen is that parent 1 opens the form and starts making changes to the data. Before parent 1 submits those changes, parent 2 opens the form and also starts making different changes to the same fields being edited by parent 1. Parent 1 then submits her/his changes. Parent 2 then submits her/his changes, overwriting the changes made by parent 1.
What I would prefer is that parent 2 would not be able to even begin making changes if parent 1 has opened the form. The changes made by both parents need to be captured, and not overwritten.
The method of using the timestamp as I describe in my initial post can be used to prevent parent 2 from overwriting the data, but it also will mean that they'd have to reload the form to see the changes submitted by parent 1, and in doing so, would lose any of the edits they'd made in the form prior to them trying to submit it and getting the notice to reload. I'd like to avoid them having to re-enter their changes, and the only way to accomplish this seems to be to prevent them from even opening the form if it is already being edited, but I'd want that "lock" on the form/data to timeout after an hour or so in case parent 1 walks away with the form open but unsubmitted.
*****To answer a question by "ThisSuitIsBlackNot": Each parent can edit the same fields. One field asks for activities in which the parents are involved. Let's say Parent 1 enters five activities. If Parent 2 sees the form before Parent 1's edits have been submitted, he/she may enter completely different items, which upon submission would overwrite the activities submitted by Parent 1. If, on the other hand, Parent 2 could be stopped from accessing the form until after Parent 1 has finished her/his edits, then when Parent 2 can load the form, she/he will see everything that Parent 1 entered, rather than an empty form field, and may choose to modify what Parent 1 submitted, overwrite it completely, or not make any changes.
There's a reason you're not finding any info on how to do this. It is a very tough problem that no one has a good solution for regardless of which tech stack you're using. In your case, I'm not convinced that it is actually a terribly important issue to solve because the data does not seem crucial or mission critical. And besides, if there are changes they will likely be the same.
I've been in many design discussions where this issue came up. After hours of arguing the result is always the same: Last one in wins.
That said, here are a couple of simpler ideas you could try:
Simply email both parents (or whoever's registered as a guardian) whenever data on that page changes. This solution is stupid simple and easy to implement. If you're already using email services in other parts of the app then it becomes nearly trivial.
Not so simple: Whenever a request is made to edit the data, create a hash of the data as is to send back with the response to the client. When the edited data is sent in to update the row, check the data against the hash. If the hashes don't match it means that someone else has modified the data while the other parent was looking at it. The trouble with this solution is that you have to create these hashes and lug them around through several layers of the app making your programming non-trivial.
This statement caught my eye in a later edit of your OP:
The changes made by both parents need to be captured, and not
overwritten.
That single business rule actually makes things quite simple for you. All you need to do is to ALWAYS create objects when they do not have a unique identifier (probably 0 or -1). When objects do have an ID, meaning they have already been created, you simply update.
There is an assumption here that edits will likely be performed non-destructively on the same data. e.g. One parent creating an activity and the other parent editing it. There is a chance of duplicate activities but that's a situation easily resolved with a delete.
This way, no one parent can overwrite the other's data blindly and unknowingly.
Regardless of what you do though, do not try to find a perfect solution. It just doesn't happen. I know, I've been writing line of business apps for over 15 years. Apply your time and talents to something that you can get right, which the application and its business rules.
I would suggest reading up on database isolation levels. I believe MySQL defaults to repeatable read. You can confirm your isolation level at the DB level by running "SHOW GLOBAL VARIABLES LIKE 'tx_isolation';" Each transaction in this configuration is already placing a lock. Whether it is getting a row level or escalating depends on factors such as how indexes are being hit etc, by the query. If you fire off transaction A to update a record then subsequently fire off transaction B, transaction B is already in a holding pattern until transaction A completes its work in this configuration. If you set this to read commited, reads no longer block each other with locking (updates, etc still place locks). In lieu of implicit locks on reads you can be explicit using the select for update to try and force a lock on the read.
I mention brushing up on locking mechanics as trying to brute force locking without extreme knowledge of the back end DB mechanics can lend itself to deadlock central.
It seems like in your scenario this is more about user perception that what they are reading is up to date when they submit the changes. The DB is really doing it's job as designed. I have seen architecture to address this user perception issue by only allowing one user in a record at a time (locking out other users from the record while someone is it) handled in some middle ware code, etc. Or by using SOA architecture to push notifications to users in the record that a changed occurred by another user.
I want to be able to track any changes made to any of the fields in an existing table. The scenario is as follows:
the user opens the datasheet view for an existing table in MS Access 2007/2010
updates values in 2 fields and 5 rows (10 cells)
saves the table (overwrites it)
I want to be able to push the changes (10 changes/rows) to a new table and then be able to open it in datasheet view to refer to it. Is there a way I can do this in access without using form?
In 2010 and later you can use data macros, or what often other systems called table triggers.
You cannot in 2007.
Keep in mind that your use of the term “save table” is VERY wrong in the context here. In fact VERY wrong in the context of most databases. The user does not “save” the table.
You can ONLY edit ONE ROW at a time in a datasheet. When you move off that record then the ROW is saved (not the table). , and if you move off, then the record is saved.
In 2010 and later, you have use of table procedure code. This thus will allow one to use a table trigger.
So 2010 and later does support table triggers and store procedure code. But since your question in includes Access 2007, then my suggestion to use table triggers (called data macros) may not work unless you can restrict users to 2010 and beyond.
In the follow example, when a user updates a row, then a “audit” table is updated with the user information. The function fosusername() is in fact a VBA function. This code is called from the before change update event for the table.
Of course the problem here is the VERY basis of your question assumes that users save a table – they don’t, they edit + save “single” records, or a single row at a time. So figuring “out” how a user is done would certainly be a challenge. So while code can be run when the users edit data, having table code run “when” the user closes the table is not possible.
As the end of the day, it likely best you create a datasheet that looks just like the table, and then change a few settings to “lock down” and prevent the user from using tables directly.
As far as I know there is no solution for this without using a form. I do not know of events (like a change or dirty event) for the actual data tables.
In a form you could use the dirty property to make sure you fetch the data. You can make the form look like a datahseet with DoCmd.RunCommand acCmdDatasheetView or set the form in datasheet view on default.
In a Related Tables, you need to enter a FK to link to the parent table.
You either key in the FG from memory !!!!!! or use help.
The standard procedure is to design the field as combo box AND use SQL to select the field that will help to input the ID of the parent table. So, if you want to input foreign key 3 , the combo box will display what 3 is then when you selected Access will insert 3 for you.
My question is since I can later on, edit the table and change the the value to another value, and mess the whole thing up!!! HOW can I lock my first choice so it will stay unedited ?
My second question is: Is this the only way to input the FK if you do not remember the exact ID number or there are thousands of records in the parent table.?
Re. #1
In Access 2010 you could use a trigger to check whether the value has been used in another table as a FK and not allow the change. In previous versions all you could do, would be to hide the navigation pane or make the table hidden.
Re. #2
You could use a listbox (basically the same idea as a combobox).
You could include the lookup table in the underlying query, but then there is more danger of the values getting changed, which is exactly what you were worried about in the first question.
Stick with the combobox.
You can create different versions of a form. One might have Allow Edits, No, another might be Data Entry, Yes, meaning that it can only be used to create new records.
However, suppose someone is creating a new record and they select the wrong FK by mistake. How can they correct this? You could use VBA to produce a confirmation dialog in the first instance, and perhaps an Undo button where VBA would deliberately perform the Undo. Access 2010 also has Data Macros (equivalent to triggers) that you might use to store the old and new values, and other information, when a user changes a FK value.
Access does not implement user-level security, so the user can still open and change data in the raw-data tables. You should, however, have enforced referential integrity on the table-join, so that a user cannot enter a FK that doesn't already exist as a PK in the related table.
In summary, you could add additional columns to the combobox to help the user select the correct item, and you might consider an additional confirmation dialog (a MsgBox) before a record is saved into the data-table. But you cannot prevent people from making mistakes. (Enforcing Referential Integrity will prevent nonsense data from being entered.)
Second question:
A combobox (or possibly a listbox) is the easiest way for users to enter a FK value, without relying on memory. An alternative would be to use a button (or other control and event) that opens a secondary form. This form might have some filtering features to help the user find the correct FK value. When this form is closed you would then need to write some code to update the relevant control on the main form.
I created 2 tables; Assets and AssetMovements. I also created the main Assets form and an Asset Movement form. The Asset Movement form is essentially a replica of the Assets form but it has the AssetMovements table as it's record source. I created a lookup in the AssetMovements table (AssetTag field) so a user can select an asset tag from a combo box and the details of that asset will be populated automatically into the rest of the fields on the form. The only editable fields on the form are the 'Location' and 'AssignedTo' field which refers to the employee.
Right now, everything works fine, but the problem is that if I create a new record using the AssetMovements form and save it, the 'Location' field in the original record which resides in the 'Assets" table will not be updated. Same goes for the 'AssignedTo' field in the original record.
Is there a way to update the main asset record in the Assets table whenever a new AssetMovement is created on that record?
It sounds like what you are trying to do is track the history of an Asset (where and who it belongs to). The natural way to do this is to update the Asset, and record the change in the AssetMovements table.
In many databases, you can use triggers to accomplish this. Whether you update an Asset through the UI or direct SQL queries, it never fails. However, MS Access does not have triggers per se. So you would be limited to doing so in the UI.
You could do this in the UI by adding an After Update event to the form, and the copying the changed record to AssetMovements. Not the other way around. Otherwise, in the case of a new Asset, you are creating an AssetMovement first, and then creating the Asset.
I've used HansUp's suggestion as well - i.e. just putting the location/assignment in AssetMovements, and displaying the most recent value on the form/report. What I dislike about this is that it makes the form a little more complex and if you have a lot of updates happening you could end up with a performance hit.
Then again, if your DB gets large enough that the performance hit is noticeable, you should probably be migrating the data to another kind of database anyway.
If I enable change-data-capture for a table, and then somebody else adds a column to the table, will my capture be affected? Will I still get updates for the original columns? For the new column?
What if a column is deleted?
(This answer from my colleague Steve, but he doesn't have a SO account so I'll post it...)
If you ADD a column, the CDC does not change ... you continue to receive updates on the same column set as before.
If you DELETE a column, the CDC continues to capture changes, but the deleted column will always have the value NULL.
If you ALTER a column, the CDC continues to capture changes, but values in the altered column will have the new column type.
From MSDN's About Change Data Capture (SQL Server)
"Handling Changes to Source Tables
To accommodate column changes in the source tables that are being tracked is a difficult issue for downstream consumers. Although enabling change data capture on a source table does not prevent such DDL changes from occurring, change data capture helps to mitigate the effect on consumers by allowing the delivered result sets that are returned through the API to remain unchanged even as the column structure of the underlying source table changes. This fixed column structure is also reflected in the underlying change table that the defined query functions access.
To accommodate a fixed column structure change table, the capture process responsible for populating the change table will ignore any new columns that are not identified for capture when the source table was enabled for change data capture. If a tracked column is dropped, null values will be supplied for the column in the subsequent change entries. However, if an existing column undergoes a change in its data type, the change is propagated to the change table to ensure that the capture mechanism does not introduce data loss to tracked columns. The capture process also posts any detected changes to the column structure of tracked tables to the cdc.ddl_history table. Consumers wishing to be alerted of adjustments that might have to be made in downstream applications, use the stored procedure sys.sp_cdc_get_ddl_history.
Typically, the current capture instance will continue to retain its shape when DDL changes are applied to its associated source table. However, it is possible to create a second capture instance for the table that reflects the new column structure. This allows the capture process to make changes to the same source table into two distinct change tables having two different column structures. Thus, while one change table can continue to feed current operational programs, the second one can drive a development environment that is trying to incorporate the new column data. Allowing the capture mechanism to populate both change tables in tandem means that a transition from one to the other can be accomplished without loss of change data. This can happen any time the two change data capture timelines overlap. When the transition is effected, the obsolete capture instance can be removed.
Note Note
The maximum number of capture instances that can be concurrently associated with a single source table is two."