Where To Store Configuration File for This App
-
No, there will be one serialized fiel that is read in on startup. But each user running it gets the data read in and could potentially change it. So how do I manage multiple people using that same XAML file?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
Quote:
So how do I manage multiple people using that same XAML file?
You don't; what you are offering is a recipe for disaster. Your application should read the file and then use a dialog/form to get any required changes from the user. As an experienced developer I am surprised you are considering such an option.
-
Quote:
So how do I manage multiple people using that same XAML file?
You don't; what you are offering is a recipe for disaster. Your application should read the file and then use a dialog/form to get any required changes from the user. As an experienced developer I am surprised you are considering such an option.
There IS going to be a dialog for Customers and their options. I didn't mean they will use an editor to change settings. But that doesn't solve the issue of more than one person modifying it at the same time. Since this is just a serialized file (XML) that contains the app's info (List of customers and their processing options), and I likely can only store that file in SharePoint, then I'm stuck with how to keep users from overwriting each other's changes. Scenerio: User A opens the app, which reads the app's data from SharePoint as a serialized collection. The user decides to modify a customer's settings and clicks save, which writes it back to SharePoint. User B then changes the same. User A's customer settings are now out of sync with user B.
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
-
When I say config file here, I mean a serialized copy of the app's data. Since there's no database, then I need to store the app's data somehow, and a serialized file seems like the way to go. But all users need access to that file, as it has to load on startup. And, each user could alter that data and save it.
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
That description does not sound like a configuration file. Everything suggests you want a database but have decided you are not going to use one. Note that all of this requires a shared data location otherwise it is pointless to even discuss this. If you have customer data then you need to store it in one location. If you have user data then you store it in an different location. If there is shared data then you will need to hack a solution that is in fact a database. Database servers handle the concurrency issue by being in process and by using locks either at the table level or the row level. You can implement something like that by using data. The data is a marker that each app must look for before it attempts to write. If it is there then the user must refresh before they can update. Problem with that is if the user computer exits or the network goes down the lock file is still there so you will need to provide a way to force it. The granularity and layout is something you would need to design and implement.
-
There IS going to be a dialog for Customers and their options. I didn't mean they will use an editor to change settings. But that doesn't solve the issue of more than one person modifying it at the same time. Since this is just a serialized file (XML) that contains the app's info (List of customers and their processing options), and I likely can only store that file in SharePoint, then I'm stuck with how to keep users from overwriting each other's changes. Scenerio: User A opens the app, which reads the app's data from SharePoint as a serialized collection. The user decides to modify a customer's settings and clicks save, which writes it back to SharePoint. User B then changes the same. User A's customer settings are now out of sync with user B.
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
Kevin Marois wrote:
The user decides to modify a customer's settings and clicks save, which writes it back to SharePoint. User B then changes the same. User A's customer settings are now out of sync with user B.
As described that is a invalid business scenario. Businesses do not have two people working on changing a customer at the same time. A sales person might update an address and an order entry person might add an order but those are different data operations even if for the same customer. But there will never be two people attempting to change the customer address at the same time. And if you are doing actual order entry then good luck because you are going to need to implement a full database yourself before your application can even work. Hopefully you are getting paid by the hour.
-
There IS going to be a dialog for Customers and their options. I didn't mean they will use an editor to change settings. But that doesn't solve the issue of more than one person modifying it at the same time. Since this is just a serialized file (XML) that contains the app's info (List of customers and their processing options), and I likely can only store that file in SharePoint, then I'm stuck with how to keep users from overwriting each other's changes. Scenerio: User A opens the app, which reads the app's data from SharePoint as a serialized collection. The user decides to modify a customer's settings and clicks save, which writes it back to SharePoint. User B then changes the same. User A's customer settings are now out of sync with user B.
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
All I can say is that your design is wrong, and needs a rethink. If user A changes the file and rewrites it, then whatever user B reads in may be invalid. The only way I could see this as a possibility is if the update file is rewritten to each user's local disk. But again that will present its own problems.
-
There IS going to be a dialog for Customers and their options. I didn't mean they will use an editor to change settings. But that doesn't solve the issue of more than one person modifying it at the same time. Since this is just a serialized file (XML) that contains the app's info (List of customers and their processing options), and I likely can only store that file in SharePoint, then I'm stuck with how to keep users from overwriting each other's changes. Scenerio: User A opens the app, which reads the app's data from SharePoint as a serialized collection. The user decides to modify a customer's settings and clicks save, which writes it back to SharePoint. User B then changes the same. User A's customer settings are now out of sync with user B.
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
You're going against the customers' architectural strategy. What you have "stuffed" into XML is the equivalent of a Sharepoint "list" or 2, that can be secured and shared twenty ways to Sunday, and accessed from WPF (if need be) via CSOM (SP client side object model)
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
There IS going to be a dialog for Customers and their options. I didn't mean they will use an editor to change settings. But that doesn't solve the issue of more than one person modifying it at the same time. Since this is just a serialized file (XML) that contains the app's info (List of customers and their processing options), and I likely can only store that file in SharePoint, then I'm stuck with how to keep users from overwriting each other's changes. Scenerio: User A opens the app, which reads the app's data from SharePoint as a serialized collection. The user decides to modify a customer's settings and clicks save, which writes it back to SharePoint. User B then changes the same. User A's customer settings are now out of sync with user B.
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
XML is NOT a database and you're trying to treat it like one. This will go badly for you. Period. There is no multi-user solution for an XML file, or any file for that matter.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
I am going to be creating a payment processing application using WPF for a client of mine. The app will prompt the user to select two files from a customer, crunch some numbers, and produce some output files. The input and output files will all be stored in SharePoint. Here's the problem: My client doesn't have a network. They store all their data in ShaarePoint, so there's no way for me to use a database. The app has customer defintions, such as types of files, file layout info, processing options, etc. I can serialize all of this into an XML file, but problem is where to put the file? I could store it in SharePoint also, but there are multiple users. So if a user runs the app, starts making a change to a customer's configuration, then another user runs the app, makes a change, and saves BEFORE the first user is done, there will be lost data. I'm open to suggestion
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
Why not make the application acquire an exclusive lock on the file whenever it's being edited? That will definitely prevent corrupted changes. EDIT: On second thought, even this wouldn't work because a person might still write an older version of the file when committing changes.
The difficult we do right away... ...the impossible takes slightly longer.
-
Why not make the application acquire an exclusive lock on the file whenever it's being edited? That will definitely prevent corrupted changes. EDIT: On second thought, even this wouldn't work because a person might still write an older version of the file when committing changes.
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
On second thought, even this wouldn't work because a person might still write an older version of the file when committing changes.
So, either lock the file, read what you need to make a decision, and write it back, in one go. Or, if you require some time to ponder the changes: Read lock, take note of the last modification time, read, release. Do all your pondering, preparing your changes. When changes are ready to be written: Exclusive lock, check time of last modification. If later than the one you saw the first time, read the new data, release and repeat from the pondering step. If write timestamp is unchanged, write your new data and release. This is a file system version of database 'optimistic locking'. With database transactions, you should always be prepared for a rollback if some other transaction modifies data you have based your calculations on. I am not saying that all database applications are prepared for rollback, only that they should be :-). Databases with optimistic locking favors short transactions: The shorter the time span from data are read to the commit, the less risk for someone else making modifications inbetween. Your DIY optimistic file system locking is similar: Do all the preparations that you can do without reading the file, leaving the minimum work between reading and writing, to reduce the risk of a rollback. But you must be prepared for it, forcing you to read the updated data before attempting a redo transaction.
-
I don't let "multiple users" change "configuration files". It's usually password protected and should be administered by a "responsible" person with the understanding "bad things will happen" if you fix it and it isn't broken.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
[
Castles Plaza Real Estate
](https://castlesplaza.com/)is a prominent real estate agency specializing in luxury properties and premium real estate services.
