June 22, 2018 at 12:54 pm
jcelko212 32090 - Wednesday, June 20, 2018 1:12 PMKGNH - Wednesday, June 20, 2018 5:53 AMDo you have any idea how useless that would be? One account would prevent anyone else from making updates, severely limiting productivity. It's pretty clear that multiple people have to be able to make updates, just not more than one of them to the same row during the duration of the first one to start editing. What you suggested indicates you didn't understand anything posted before.
The whole point of using DCL to control access to the database is to limit it to one user! Many decades ago, I consulted for a company that did not have any controls. All the developers were given full data admin privileges on an Informix database. And they all used it.. In particular, they were getting information on doctors from two different sources (Medata and Phoenix Data). The updates to the database which salesman used varied from day-to-day, depending who had loaded which tape when. The two systems had different encoding schemes, different timeliness, etc. This was so long ago that the CASS standards had not been established for adresses, etc.
When we moved the privileges away from the developers, and put it in the control of the gatekeeper for that particular database, we finally got consistent quality. Suddenly the doctor specialties were encoded the same way, the addresses were all formatted the same way, the phone numbers were checked for validity, etc. perhaps even more important, was the fact that we now had single entry points and assigned responsibility for the data we were using. We knew when the tapes are going to be loaded. We knew that they were going to be loaded only after they had gotten a good data scrub.
Later, he found another advantage to using the DCL. While not 100% portable from one database to the other (yes, there are shops that have more than one kind of database or who do business with companies that have another database product), the DCL scripts were close enough, so it was easy to port them. And since you were using a standard DCL, whenever one of the vendors improved their database product, we simply recompiled and got the benefits.
You completely missed the point. Limiting the access to one user isn't going to make the concurrency problem go away. Even if all the users are using the application's sole user id to access the database, that one user id is still going to experience a concurrency issue going after a single row via more than one actual user. The problem the user described is that of "last one in wins". This is problematic of one user reads the row before another, but updates it only AFTER the other user updates it, effectively wiping out the other user's changes. You don't solve that problem with a single user limitation. This is a serialization problem.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
June 22, 2018 at 1:16 pm
Thom A actually provided a possible solution, and it has to be implemented in the application. It would also have to be serializable to accomplish the lock. The application would also have to verify if the row is locked before attempting to lock the selected row of data.
This is not going to be solved in the database alone.
June 22, 2018 at 3:08 pm
Lynn Pettis - Friday, June 22, 2018 1:16 PMThom A actually provided a possible solution, and it has to be implemented in the application. It would also have to be serializable to accomplish the lock. The application would also have to verify if the row is locked before attempting to lock the selected row of data.This is not going to be solved in the database alone.
I really hate implementing things in an application. As a database lives on, there is usually more than one application for that data. That's why we put things in a database! Universal access to consistent data.
>> It would also have to be serializable to accomplish the lock. The application would also have to verify if the row is locked before attempting to lock the selected row of data. <<
And this can get expensive in any database product which I know.
>> This is not going to be solved in the database alone.<<
In my pharmaceutical company example, they had to set up a set of processes at the business level for controlling their data. Developers would had full admin privileges to just the salesman's database bloody murder when they could no longer do alter table statements at will and make updates as they felt like it.
Back in the late 60s, when I was doing a lot of DOD stuff, I had a boss who stressed the quality of our code and data. Gus used to say, "get it right! You might kill the wrong people" ; we had no illusions about the real purpose and consequences of defense contracting and later medical systems.
Please post DDL and follow ANSI/ISO standards when asking for help.
June 22, 2018 at 3:35 pm
jcelko212 32090 - Friday, June 22, 2018 3:08 PMLynn Pettis - Friday, June 22, 2018 1:16 PMThom A actually provided a possible solution, and it has to be implemented in the application. It would also have to be serializable to accomplish the lock. The application would also have to verify if the row is locked before attempting to lock the selected row of data.This is not going to be solved in the database alone.
I really hate implementing things in an application. As a database lives on, there is usually more than one application for that data. That's why we put things in a database! Universal access to consistent data.
>> It would also have to be serializable to accomplish the lock. The application would also have to verify if the row is locked before attempting to lock the selected row of data. <<
And this can get expensive in any database product which I know.
>> This is not going to be solved in the database alone.<<
In my pharmaceutical company example, they had to set up a set of processes at the business level for controlling their data. Developers would had full admin privileges to just the salesman's database bloody murder when they could no longer do alter table statements at will and make updates as they felt like it.
Back in the late 60s, when I was doing a lot of DOD stuff, I had a boss who stressed the quality of our code and data. Gus used to say, "get it right! You might kill the wrong people" ; we had no illusions about the real purpose and consequences of defense contracting and later medical systems.
Really don't care Mr. Celko.
June 22, 2018 at 3:53 pm
jcelko212 32090 - Friday, June 22, 2018 3:08 PMBack in the late 60s, when I was doing a lot of DOD stuff, I had a boss who stressed the quality of our code and data. Gus used to say, "get it right! You might kill the wrong people" ; we had no illusions about the real purpose and consequences of defense contracting and later medical systems.
You know it's 2018 now, right Joe? I don't think 1960's logic really applies very much anymore. Things that worked back then are terrible ideas now. It's time to move into the 21st century.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
June 24, 2018 at 11:27 am
jcelko212 32090 - Friday, June 22, 2018 3:08 PMYou know it's 2018 now, right Joe? I don't think 1960's logic really applies very much anymore. Things that worked back then are terrible ideas now. It's time to move into the 21st century.
You've just posted in a public forum, where future employers using AI, will find your attitude toward data quality. I don't know how to tell you this but accurate data is not an option. In many situations, such as medical or defense, people die or are maimed. It doesn't matter what your tools are; it matters what your attitude toward data quality is. You use the best tools you have at the time to reach this goal.
Please post DDL and follow ANSI/ISO standards when asking for help.
June 26, 2018 at 6:26 am
Thom A - Friday, June 22, 2018 3:53 PMjcelko212 32090 - Friday, June 22, 2018 3:08 PMYou know it's 2018 now, right Joe? I don't think 1960's logic really applies very much anymore. Things that worked back then are terrible ideas now. It's time to move into the 21st century.
You've just posted in a public forum, where future employers using AI, will find your attitude toward data quality. I don't know how to tell you this but accurate data is not an option. In many situations, such as medical or defense, people die or are maimed. It doesn't matter what your tools are; it matters what your attitude toward data quality is. You use the best tools you have at the time to reach this goal.
And then they'll see your attitude and laugh their collective butts off at us for allowing you to continue posting utterly irrelevant and off-topic and useless information repeatedly without consequence.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
July 5, 2018 at 9:05 am
Thom A - Friday, June 22, 2018 3:53 PMjcelko212 32090 - Friday, June 22, 2018 3:08 PMYou know it's 2018 now, right Joe? I don't think 1960's logic really applies very much anymore. Things that worked back then are terrible ideas now. It's time to move into the 21st century.
You've just posted in a public forum, where future employers using AI, will find your attitude toward data quality. I don't know how to tell you this but accurate data is not an option. In many situations, such as medical or defense, people die or are maimed. It doesn't matter what your tools are; it matters what your attitude toward data quality is. You use the best tools you have at the time to reach this goal.
Joe, do us all a favor and just go away
July 6, 2018 at 3:03 am
Thom A - Tuesday, June 26, 2018 3:48 PMKGNH - Wednesday, June 20, 2018 11:49 PMThanks every one for your suggestionsHow did you implement your solution in the end, out of interest?
Hi Thom,
Actually this was done from application. Initially I thought will there be any way to lock at database level but later I just hold the value in a table if any user started working on that and making it readonly till the record exist in the table. Once it was done it will be removed from the table.
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply