It's a struggle with any application that provides select fields, that are populated by a certain datasource: Everything works fine in the first place, but once the application ages, some older entries might be deleted, leading to the problem that prior select fields can no longer access the entity in question.
Opening a view, where a select points to an already deleted datarow will (best case) show empty string.
We designed our system in a way, that deletions are not real delete-operations, but only the setting of a deleted flag. (So, all the information is still there)
However, when using Databindings along with C# (or even if not) the most blatant use case is still not covered by general mechanics (I assume):
Select-Field should show all NOT-Deleted-Entities while creating a new object containing references to the entity in question.
Select-Field (populated the very same way) should show the "deleted" entity, if it was selected "days/months/years" ago.
Is there a "handy" solution to this?
Currently we are using a "Proxy-Method" for every datasource, which will reload the data of the deleted entity, if it's not in the "available data" collection - but it's hard to believe there is no better way to deal with this, as this problem applies for almost every language out there?
In a normalized database you would have a constraint with ON DELETE NO ACTION/RESTRICT event that would prevent removal of a referenced element from the list. It would force you to decide what is to be done with the referencing rows.
With your manually-controlled deletions this could have been covered by a trigger. As none of these were implemented, you are left with only one thing to do: updating the dropdown with the selected option before rendering the UI. My approach (in Java, I'm not good at C#):
List<String> options = getNonDeletedWhatever();
if (!options.contains(currentEntity.getWhatever())) {
options.add(currentEntity.getWhatever()); // This optionally inserts an outdated value
}
or simply:
Set<String> options = getNonDeletedWhatever();
options.add(currentEntity.getWhatever()); // This optionally inserts an outdated value
I solve it by creating a list of available (non-deleted) items and if the selected item is a deleted one, then I add that item to the list.
This list becomes the data source for my dropdown.
Related
I am looking at Dapper as ORM for our next project, but something is not clear to me.
In this question there are answers on how to do inserts, updates and deletes.
Since this question is already a bit older, maybe there are better ways now a days..
But my biggest concern is how to do an ApplyUpdates on a list.
Suppose you have a List<Customer> that is build like shown here
And suppose you show this list in a DataGridView.
Now, the user will
alter the data of a few rows,
insert a few new rows,
delete a few rows
And when he clicks on the save button, at that time you want to save all these changes in this List<Customer> to your database, using Dapper.
How can I go about that ?
If I have to loop through the list and for each row call an insert, update or delete statement, then how can I determine what operation to use ? The deleted rows will be gone from the list.
I also want to make sure that if one statement fails, all will be rollbacked.
And I need the primary key for all new rows returned and filled in the DataGridView.
In other words, all that ADO DataAdapter/DataTable does for you.
What is the best way to do this using Dapper ?
EDIT
The best way I can think of now is to keep 3 list in memory and when the user alters some data, add a row in the update list, same for insert list and deleted list so I can run through these 3 list on the button click.
But I am hoping there is a better alternative build in Dapper for this kind of situation.
You need to handle this yourself, as Dapper doesn't manage it. There are several theories for how to do it.
Delete all items and then add them again.
Easy to implement.
Bad for DB performance, which is effectively 2 DB writes per row.
Loop through the items and update without checking for changes
Not too difficult to implement.
DB performance better than option 1, but not ideal.
Add and deletes are more complex to detect than updates.
Loop through the items and update only if there are differences
More difficult to implement.
Requires reading from the DB first to compare values (extra DB action)
Store changes in a separate list
Even more difficult to implement, as you need to "wrap" List updates into another class (first class collection?) and store changes
Most efficient for DB, as you execute only the minimum on each DB item.
In the end, you might select different approaches for different Entities depending on how you need to optimise. e.g. Option 1 is fine if you know you will only have a few entities and not many updates.
I have a Sharepoint list on a site that I want to update nightly from a SQL server DB, preferably using C#. Here is the catch, I do not know if any records were removed, added, or if any field in any record has been updated. I would believe then the simplest thing to do is remove the data from the list and then replace it with the new list data. But is there any simple way to do this? I would hate to remove 3000+ items line by line from the list and then add the 3000+ records one at a time.
Its up to your environment. If you not that much load on the systems in the night, i would prefer one of the following ways:
1) Build a timerjob, delete the list (not the items one by one, cause this is slow), recreate the list and import the items from the db. When we are talking about 3.000 - 5.000 Elements, this is not that much and i think done under 10 Minutes.
2) Loop through the sharepoint list with the items and check field by field if it was updated within the db and if yes, update it.
I would preferr to delete the list and import the complete table, cause we are talking about not that much data.
Another way, which is a good idea, is to use BCS or BDC. Then you would have the data always in place and synched with the db. Look at
https://msdn.microsoft.com/en-us/library/office/jj163782.aspx
https://msdn.microsoft.com/de-de/library/ee231515(v=vs.110).aspx
Unfortunately there is no "easy" and/or elegant way to delete all the items in a list, like the delete statement in SQL. You can either delete the entire list and recreate it if the list can be easily created from a list definition or, if your concern is performance, since SP 2007 the SPWeb Class has a method called ProcessBatchData. You can use it to batch process commands to avoid the performance penalty of issuing 6000 separate commands to the server. However, it still requires you to pass an ugly XML that contains a list of all the items to be deleted or added.
The ideal way is to enumerate all the rows from the database and see if each row already exists in the SharePoint list using a primary field value. If it already exists, simply update them[1]. Otherwise you can add a new item.
[1] - Optionally, while updating them we can compare the list item field values with database column values. Only if there is a change in any of the field, update it. Otherwise skip it.
I'm having some serious issues with setting an items values be _StandardValues in sitecore. I have a sitecore item and I retrieve it's data simply thus:
Item rawItem = service.Database.GetItem(new ID(id));
I subsequently extended said item's template and added a new TreeListEx. I populated this treelist from standard values:
The problem is the standard values are not getting retrieved by the above code. The field does not exist in the fields collection. What is confusing is if I change the items values, so remove all the standard items and put them back in, it works. The only thing in the UI appears different is that the field goes from:
to
i.e. it's not pulling this data from [standard values] anymore. I can now see my fields in rawItem (above).
If I check the Raw values of the they are identical (i.e. a collection of Guids as you'd expect):
{4E4A364E-16D5-4E09-A4E7-25DB628951FB}|{15E4026A-575A-4787-83B0-A37EB9F0A06D}|{74D1C654-BE53-4FB4-A072-19DA70215F4B}|{C3883CDE-A01E-46B7-B09F-2FB1F4C51C3A}
Has anyone else experienced this issue? Am I missing something?
I think I got a solution, it just came back to life. It appears that I needed to rebuild the link DB. I had tried this previously to no avail, but the difference this time is I rebuilt all 3 (core, web and master) DBs:
Hopefully this will help someone with this issue in the future.
I have this problem and I don't know what is the best solution for it.
I have table called Employees and there is column called LastWork, this column should only have custom values I choose for example:
value 1
value 2
and I want the user to select the value from ComboBox control so I have 2 ideas for it but I don't know what is the best for it.
A - add these value to Combobox as string in Items property and store them as string in DB.
B - create separate table in my db called for example 'LastWork' with 2 columns 'LastWorkID', 'LastWorkName' and insert my values in it, and then I can add binding source control and I can use data bound items to store the id as integer in my main table and show the LastWorkName for users.
I prefer to use the B method because in some forms I have DataGridView control with edit permission, and I want to display Combobox in it instead of Textbox to select from these custom values.
I hope you understood my questions.
Normally data normalization is a good thing, so I too would go with your option B.
By having a separate table and a foreign key relationship to it, you can enforce data integrity; easily get a list of all available (not just all selected) options; have a single place in which to change the text of an option (what if someone decides to call it "value one" instead of "value 1", for example?); and so on and so forth.
These might not be huge benefits in a small application and with only two possible options, but we all know that applications very often tend to grow in scope over time.
In a normalized database, your "option B" is usually the way to go because it eliminates duplicate data. It will potentially introduce an additional join into your queries when you need the name (and not just the ID), but it also allows you to rename lookup names easily without altering their underlying IDs.
For performance reasons, it's often a good idea to cache lookup values such as you describe in the business tier so that your lookup table is not hit over and over again (such as when building many rows of a grid).
I would always save them in the db. If you have to localize your app, this helps alot. Additonally, it let you to apply the referential integrity checks of the database.
Many of you may have noticed that since RC1 you don't have to include the .Index hidden field to enable complex model binding. However one of the drawbacks is that now you have to have the index starting from 0 and it cannot break. eg. skip from 4 to 6 etc.
With the old syntax I was able to just remove the item from the DOM and when the form submitted, all items except for the deleted one were posted. However with the new syntax if I remove index 5 then only 0-4 will be posted, because the index has broken.
How do you handle deleting an item from a list now?
Yes, the 'unbroken index' thing is a nuisance! There are 2 ways I have handled this in my projects:
The first way is by making the delete method on the client replace the whole list with fresh html from the server. This is fine for small lists and it's 'easy' as the index sequence is regenerated on the server.
With bigger lists that's not efficient though and in that situation I prefer to reorder the indexes with jquery on the client.