Design and Architecture

11-Sep-23 11:04

Working on a WPF app. Currently, I have a table in SQL called Lookups that contains all kinds of lookup data.

Here is a set of that data called Employee Types.

<h2>Caption                       Category                      AppCode</h2>

Director of field Operations  employee_types                director_of_field_operations
Drafting                      employee_types                drafting
Driver                        employee_types                driver
Estimator                     employee_types                estimator
Foreman                       employee_types                foreman
General Forman                employee_types                general_forman
Office                        employee_types                office
President                     employee_types                president
Project Coordinator           employee_types                project_coordinator
Project Manager               employee_types                project_manager
System Administrator          employee_types                system_admin
Vice President

Each employee is assigned an Employee Type. I can the query for specific types of employees. For example, there is a Foreman report that gets all employees who's EmployeeTypeId is in the Lookups of AppCode 'foreman' or 'general_forman'. The AppCode is defined by me when I create new Lookup entries so I can reference them in code.

The problem is, now my client wants to be able to add and remove employee types via the UI.

I don't see how I can allow them to manage this list without the AppCode. I would have nothing to key off of when running reports or sending automated notifications to people in specific roles.

I can provide more detail if needed.

Any ideas on this?

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.

Mycroft Holmes11-Sep-23 12:01

Mycroft Holmes

11-Sep-23 12:01

When they create a new type (via a dialog) check for existing, then suggest a "code" based on the entered content after checking for an existing code.

This is the drawback of using a "code" and also storing different types of data in the same table - classic mistake. I know the argument that they are all lookups and they are all simple UNTIL THEY ARE NOT! You now have to faff about working around the problem instead of having an EmployeeType table with an ID as the primary key.

Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP

Kevin Marois11-Sep-23 13:07

11-Sep-23 13:07

But the problem is that my code can never know what the code is.

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.

Richard Deeming11-Sep-23 21:49

Richard Deeming

11-Sep-23 21:49

As Mycroft said, stuffing every lookup into a single "lookups" table is a bad idea. It makes life much harder when you want to evolve a single type of lookup.

Start by moving the employee types to its own table. The next step will depend on your precise requirements:

If you only ever want to report on a specific group of employee types, then replace the AppCode with a lookup to an "employee type group" table. When the user adds a new employee type, let them select the appropriate group, so that those types can be included in the relevant reports.
If you need more flexible grouping for your reports, add a many-to-many relationship between the employee type and the employee type groups. You can optionally let the user add the new types to one or more groups; if they don't, then those types won't be included in the reports.

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

jschell12-Sep-23 4:51

12-Sep-23 4:51

You have an application enum and now the requirement is to allow customers to manage the enum as well.

So first decision is one of these
1. Open it up entirely.
2. Allow them their own additional enums. Only the additions can be modified.

If the there is only one customer per table (how ever you designed that) then the caption can be under user control completely for all enums with the following rules
1. Must not be empty.
2. Must not be a duplicate of another.

Then the decision is how to store them. Probably easiest is going to be to add another column which flags it as a user value.

Then the other changes
1. Provide a UI to manage them. I would just show all of them. This is required to manage the caption anyways (above.) But also allows them to see groupings. The flag controls whether they can delete them. Naturally you will need a length limit.
2. Figure out how to allow the usage.

The second is tricky if you store them in another table. Such as a custom report. If so then you must either force them to remove the usage first before deleting or you must do it yourself.

Gerry Schmitz12-Sep-23 5:06

Where To Store Configuration File for This App

12-Sep-23 5:06

... "and remove". Total disaster. Breaks referential integrity. The only way to "remove" "codes" is to "expire" them with a start and end date.

Kevin Marois6-Sep-23 12:45

6-Sep-23 12:45

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.

modified 7-Sep-23 11:29am.

Gerry Schmitz6-Sep-23 19:33

6-Sep-23 19:33

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.

Kevin Marois7-Sep-23 5:26

7-Sep-23 5:26

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.

Gerry Schmitz7-Sep-23 6:04

7-Sep-23 6:04

Sharepoint is one big database. All those "lists" ... there all SQL tables. (Or views)

Richard MacCutchan6-Sep-23 21:45

6-Sep-23 21:45

See this article by the esteemed @OriginalGriff: Where Should I Store My Data?[^].

Kevin Marois7-Sep-23 5:28

7-Sep-23 5:28

Not sure how that helps.

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.

Richard MacCutchan7-Sep-23 5:53

7-Sep-23 5:53

Quote:
each user could alter that data and save it.

Fine, but that does not prevent you from storing it wherever you wish. The biggest drawback as I see it is allowing users direct access to modify a configuration file. Or do you mean that each user has a personal copy of the data?

Kevin Marois8-Sep-23 5:51

8-Sep-23 5:51

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.

Richard MacCutchan8-Sep-23 6:13

8-Sep-23 6:13

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.

Kevin Marois8-Sep-23 7:29

8-Sep-23 7:29

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.

jschell8-Sep-23 7:55

8-Sep-23 7:55

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.

Richard MacCutchan8-Sep-23 8:01

8-Sep-23 8:01

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.

Gerry Schmitz8-Sep-23 8:20

8-Sep-23 8:20

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)

Dave Kreskowiak8-Sep-23 9:24

Dave Kreskowiak

8-Sep-23 9:24

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

jschell7-Sep-23 5:11

7-Sep-23 5:11

Kevin Marois wrote:
My client doesn't have a network.

As stated that is nonsensical with what you said in the rest of your post such as "then another user runs the app, makes a change, and saves BEFORE the first user is done". That second cannot happen unless there is a network.

Also Sharepoint is a teamwork collaboration tool. You can't use it without a network.

Perhaps you meant a shared file system.

But other than that the configuration file is either per user or there is only one for the entire company.

If per user then you store it on each computer. There is no problem.
If one per company then then since you know Sharepoint exists then use it. It has a REST API, and I would be really surprised if there was not a way to store a file. Your app can provide the management including a place for the current user to type in their Sharepoint credentials (or use some other method to authenticate.)

As for the overwrite problem...

There is something wrong with your design if you expect users to be constantly updating the configuration file all of the time. It should be something that is rarely updated and when it is updated one specific person will be tasked with doing that. It will likely be the case that only one person even knows how to do it. So it is a non-issue.

Otherwise it isn't a configuration file. It is in fact a persisted data store. And your design should have accounted for that in the first place.

Kevin Marois7-Sep-23 5:28

7-Sep-23 5:28

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.

jschell8-Sep-23 7:50

8-Sep-23 7:50

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.