Design question about access to database.
-
First a quick description of the problem. A piece of software written in VB handles a lot of stuff. 6-8 active users at a time. One module deals with planning and got 2-3 users which use this. Up until recently only one user was actively using this module but structural changes within the workforce has changed this. This has brought on a problem where changes to the planning seems to disappear for those that plan. My problem when fixing this is that I'm not 100% exactly what does what so I want to create a solution that is as small and clean as possible to fix the issues as we are moving to another system sometime within the next 4month-2years. The module queries an SQLDatabase and then renders the used table using some fancy VB6 graphics. Changes are made and then saved. When a save is made a lot of rows are deleted and then remade with the new data. I think the problem might be that what is deleted isn't just those entries that are changed but a large chunks of rows fit inside the selection criteria. This means that if 50 rows are selected and 5 changed by user A which saves if user A got the data before user B made it's changes user B's changes are overwritten if their are included inside the selection criteria. Those who use this module swear that they use the reload function correctly to make sure they got the latest data and then swiftly make their changes and saves and that in order to avoid the problem they make sure only one is editing at the time but you know... ...users. :doh: One of the things I'm working on adding is a check where I look if someone else has changed the data before saving and compare. If user A's and user B's changes doesn't overlap I will merge these instead of overwriting everything and if there are conflicts I will promt the user as to which change they want to use. This should fix it because even if the query selection returns the same set of data in a majority of cases they are working on different parts of this set. That's what I've been doing so far and will implement. Even if it doesn't fit 100% what they want this will be what they get. That should hopefully describe the current situation. Since they actually try to avoid working at the same time my boss also suggested to add a lock/semaphore to enforce the idea that only one user can edit the data. And I just wanted to get some input on a quick way of doing it. I was thinking of adding three controls/buttons and a status window. Status window will show if and who is currently editing if its lock
-
First a quick description of the problem. A piece of software written in VB handles a lot of stuff. 6-8 active users at a time. One module deals with planning and got 2-3 users which use this. Up until recently only one user was actively using this module but structural changes within the workforce has changed this. This has brought on a problem where changes to the planning seems to disappear for those that plan. My problem when fixing this is that I'm not 100% exactly what does what so I want to create a solution that is as small and clean as possible to fix the issues as we are moving to another system sometime within the next 4month-2years. The module queries an SQLDatabase and then renders the used table using some fancy VB6 graphics. Changes are made and then saved. When a save is made a lot of rows are deleted and then remade with the new data. I think the problem might be that what is deleted isn't just those entries that are changed but a large chunks of rows fit inside the selection criteria. This means that if 50 rows are selected and 5 changed by user A which saves if user A got the data before user B made it's changes user B's changes are overwritten if their are included inside the selection criteria. Those who use this module swear that they use the reload function correctly to make sure they got the latest data and then swiftly make their changes and saves and that in order to avoid the problem they make sure only one is editing at the time but you know... ...users. :doh: One of the things I'm working on adding is a check where I look if someone else has changed the data before saving and compare. If user A's and user B's changes doesn't overlap I will merge these instead of overwriting everything and if there are conflicts I will promt the user as to which change they want to use. This should fix it because even if the query selection returns the same set of data in a majority of cases they are working on different parts of this set. That's what I've been doing so far and will implement. Even if it doesn't fit 100% what they want this will be what they get. That should hopefully describe the current situation. Since they actually try to avoid working at the same time my boss also suggested to add a lock/semaphore to enforce the idea that only one user can edit the data. And I just wanted to get some input on a quick way of doing it. I was thinking of adding three controls/buttons and a status window. Status window will show if and who is currently editing if its lock
The buttons sound like a disaster waiting to happen. Give users a "Force Unlock" button and you're right back where you started. Do some reading up on locking techniques[^] If you can't get rid of the VB6 stuff altogether you could also consider a COM dll (written in a .NET language) that you could use to leverage SQL notification services - more info at Query Notification using SqlDependency and SqlCacheDependency[^]
-
First a quick description of the problem. A piece of software written in VB handles a lot of stuff. 6-8 active users at a time. One module deals with planning and got 2-3 users which use this. Up until recently only one user was actively using this module but structural changes within the workforce has changed this. This has brought on a problem where changes to the planning seems to disappear for those that plan. My problem when fixing this is that I'm not 100% exactly what does what so I want to create a solution that is as small and clean as possible to fix the issues as we are moving to another system sometime within the next 4month-2years. The module queries an SQLDatabase and then renders the used table using some fancy VB6 graphics. Changes are made and then saved. When a save is made a lot of rows are deleted and then remade with the new data. I think the problem might be that what is deleted isn't just those entries that are changed but a large chunks of rows fit inside the selection criteria. This means that if 50 rows are selected and 5 changed by user A which saves if user A got the data before user B made it's changes user B's changes are overwritten if their are included inside the selection criteria. Those who use this module swear that they use the reload function correctly to make sure they got the latest data and then swiftly make their changes and saves and that in order to avoid the problem they make sure only one is editing at the time but you know... ...users. :doh: One of the things I'm working on adding is a check where I look if someone else has changed the data before saving and compare. If user A's and user B's changes doesn't overlap I will merge these instead of overwriting everything and if there are conflicts I will promt the user as to which change they want to use. This should fix it because even if the query selection returns the same set of data in a majority of cases they are working on different parts of this set. That's what I've been doing so far and will implement. Even if it doesn't fit 100% what they want this will be what they get. That should hopefully describe the current situation. Since they actually try to avoid working at the same time my boss also suggested to add a lock/semaphore to enforce the idea that only one user can edit the data. And I just wanted to get some input on a quick way of doing it. I was thinking of adding three controls/buttons and a status window. Status window will show if and who is currently editing if its lock
Reading through the description of the system it is quite obvious that it is not suited to multiple access - particularly the deletion and re-insertion of data rather than updates. There is no manner in which you can 'fix' things that will not cause you a world of pain in the future. I would say you have 2 options: (1)Rewrite the underlying database update mechanism so that it does not makes use of deletions and inserts. (2)Leave things as they are an only allow one user to access the application at a time. Even if you do go with option (1) there is no solution to the update conflict issue. Quite simply if two users grab the same record, the person who makes the second update wins - there is no way around this no matter how much clever code you write. Given that the best minds in computer science have not yet solved this problem there is little chance that you or I will.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Reading through the description of the system it is quite obvious that it is not suited to multiple access - particularly the deletion and re-insertion of data rather than updates. There is no manner in which you can 'fix' things that will not cause you a world of pain in the future. I would say you have 2 options: (1)Rewrite the underlying database update mechanism so that it does not makes use of deletions and inserts. (2)Leave things as they are an only allow one user to access the application at a time. Even if you do go with option (1) there is no solution to the update conflict issue. Quite simply if two users grab the same record, the person who makes the second update wins - there is no way around this no matter how much clever code you write. Given that the best minds in computer science have not yet solved this problem there is little chance that you or I will.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
I went with a simple lock that relies a lot on the fact that the users use it the correct way but there are only 3 of them and I only need to reduce the amount of conflicts. Time constraints where I've got to priorities what I do kind of forced me to do what I found the easiest atm. Now the user wont be able to edit unless they own the lock so to speak and will be prompted to do this and I've gone over all the available functions and added checks to verify correct usage. Hopefully this will reduce the amount of conflicts. Their problem seems to be compounded by stress when a conflict happens because of their time constraints. If there is one they usually make more shortly there after. At this point rewriting the entire updating mechanism isn't interesting because in the not so far off future we will change systems and my work now is more to make sure it keeps afloat until that time.
-
The buttons sound like a disaster waiting to happen. Give users a "Force Unlock" button and you're right back where you started. Do some reading up on locking techniques[^] If you can't get rid of the VB6 stuff altogether you could also consider a COM dll (written in a .NET language) that you could use to leverage SQL notification services - more info at Query Notification using SqlDependency and SqlCacheDependency[^]
Will read up on locking. Seems like locking depends on using transactions which this system doesn't use at all. The entire thing is a jumble that I've inherited and I'm the third generation now I think. Won't apply it now as I went with the dirties quickest solution that is good enough for now.
-
I went with a simple lock that relies a lot on the fact that the users use it the correct way but there are only 3 of them and I only need to reduce the amount of conflicts. Time constraints where I've got to priorities what I do kind of forced me to do what I found the easiest atm. Now the user wont be able to edit unless they own the lock so to speak and will be prompted to do this and I've gone over all the available functions and added checks to verify correct usage. Hopefully this will reduce the amount of conflicts. Their problem seems to be compounded by stress when a conflict happens because of their time constraints. If there is one they usually make more shortly there after. At this point rewriting the entire updating mechanism isn't interesting because in the not so far off future we will change systems and my work now is more to make sure it keeps afloat until that time.
What happens if a user is booted out of the system while the have the lock? I guess you have to go in and manually unlock the row(s).
Member 11683251 wrote:
relies a lot on the fact that the users use it the correct way
Good luck with that because in my experience systems need to be written to either guide users or to block them from breaking a system. Relying on users to do things 'the correct way' will lead to the sort of trouble you currently find yourself in.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
What happens if a user is booted out of the system while the have the lock? I guess you have to go in and manually unlock the row(s).
Member 11683251 wrote:
relies a lot on the fact that the users use it the correct way
Good luck with that because in my experience systems need to be written to either guide users or to block them from breaking a system. Relying on users to do things 'the correct way' will lead to the sort of trouble you currently find yourself in.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
The guy that worked here before me had basically given up on user interactions. One part of the system deals with users reporting produced goods and despite numerous checks and controls people still managed to mess it up. One common mistake was that people wrote their userid where you should put the number of goods produced so headed a comparison with their userid was and if it matched with reported goods prompted user to answer if they wanted to proceed. People ended up just clicking yes anyway so instead he just added a big nope can do if they tried to do it. But I'll put my faith in to that these three can manage a few months. There is a force unlock available to avoid that and even if that doesn't work this system isn't very safe when it comes to credentials so they could just solve it by exiting and entering again and say that they are the person that owns the lock.
-
The guy that worked here before me had basically given up on user interactions. One part of the system deals with users reporting produced goods and despite numerous checks and controls people still managed to mess it up. One common mistake was that people wrote their userid where you should put the number of goods produced so headed a comparison with their userid was and if it matched with reported goods prompted user to answer if they wanted to proceed. People ended up just clicking yes anyway so instead he just added a big nope can do if they tried to do it. But I'll put my faith in to that these three can manage a few months. There is a force unlock available to avoid that and even if that doesn't work this system isn't very safe when it comes to credentials so they could just solve it by exiting and entering again and say that they are the person that owns the lock.
If I was in your position I would do this: I would create a separate application that allows me to unlock specific rows - a force unlock on all rows could cause issues if some of those rows still need to be locked. It sounds like you have inherited something of a nightmare to support.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
If I was in your position I would do this: I would create a separate application that allows me to unlock specific rows - a force unlock on all rows could cause issues if some of those rows still need to be locked. It sounds like you have inherited something of a nightmare to support.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
It can be a bit of a headache at some times. No documentation at all. The way it's build is at least fairly compartmentalized and everything follows the same flow but certain parts like this module is a bit more complex. A lot of time gets eaten up just by understanding how things are supposed to work. It doesn't help that I got a lot of duties that are quite spread out which means that when something pops up in a part which I haven't familiarized myself with it's so much harder. And lastly the entire system is a classic case of a program or suit of programs in this case which has grown in scope as different needs has come up. For example there are several types of "orders" which are stored in different tables. There are customer orders, which is the entire order of what they want and how much, shipping orders which specify when and what things are to be delivered, these are related to the customer order. Then we have at least two types of internal productions order which are there to specify when we need to produce what. All complete with poor name conventions and lack of documentation. :^) The upside is that people see me as some sort of magician when there is a problem and quickly figures it out. I'm a good problem solver but average programmer with zero database experience before I started working here and originally was hired to program robots. :laugh:
-
It can be a bit of a headache at some times. No documentation at all. The way it's build is at least fairly compartmentalized and everything follows the same flow but certain parts like this module is a bit more complex. A lot of time gets eaten up just by understanding how things are supposed to work. It doesn't help that I got a lot of duties that are quite spread out which means that when something pops up in a part which I haven't familiarized myself with it's so much harder. And lastly the entire system is a classic case of a program or suit of programs in this case which has grown in scope as different needs has come up. For example there are several types of "orders" which are stored in different tables. There are customer orders, which is the entire order of what they want and how much, shipping orders which specify when and what things are to be delivered, these are related to the customer order. Then we have at least two types of internal productions order which are there to specify when we need to produce what. All complete with poor name conventions and lack of documentation. :^) The upside is that people see me as some sort of magician when there is a problem and quickly figures it out. I'm a good problem solver but average programmer with zero database experience before I started working here and originally was hired to program robots. :laugh:
Member 11683251 wrote:
I started working here and originally was hired to program robots
Ah, in which case you need one of these[^] to fix all your user/database related problems.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
