|
What you're talking about is not handled by Transactions. Transactions make sure a group of operations on the database are handled as a single unit. They makes no claims to concurrency.
|
|
|
|
|
Correct. It's just related, but it needs us to do what you recommended in your first reply. Thats the right answer 
It's explained here[^]
modified 12-Oct-18 9:12am.
|
|
|
|
|
Simple; you don't use Access on the server. There's a button in your IDE that upgrades your Access-database to SQL Server.
Wrap your statements in a transaction, and the operation should become atomic.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Simple; you don't use Access on the server. There's a button in your IDE that upgrades your Access-database to SQL Server.
:=) made me smile.
Eddy Vluggen wrote: Wrap your statements in a transaction, and the operation should become atomic.
This way: ?
.net - How to create a LINQ to SQL Transaction? - Stack Overflow[^]
|
|
|
|
|
|
R1911 wrote: Though 'Transaction' takes care of things, it still needs us to know how to handle the exceptions.
You show the error to the user.
Something like "this app lets two people change the same text, and then can only save one of them".
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Something like "this app lets two people change the same text, and then can only save one of them".
Mate, please don't mistake. But I'm not sure why your replies are consistently sarcastic. Do you think I can apply this solution?
|
|
|
|
|
He's not being sarcastic. You are mixing two cases here:
The first case is handled through transactions which is where two records attempt to update the same record at the same time.
The second case requires more of an end user experience type of mindset and relates to the question, what happens when you have two people editing the same record but they save at different times? Consider a stock trading application. You ring trader A and tell him you want to sell a million dollars of stock. So, he gets your stock up and enters a sell order for a million dollars but then gets distracted. Now, you're watching the market and you see that selling that much stock is going to be a bad idea and you also see that you haven't sold it yet so you ring up the same trading company but get put through to trader B instead. Now, you tell trader B to just sell half a million dollars of this stock. That trader gets up the stock, sets it and processes the order and you have just sold half a million. Now trader A comes back from his very enjoyable lunch and notices that he hasn't placed the order so he presses Sell. What happens next is hugely important.
If your application treats each "transaction" atomically and just processes it, you have just sold 1.5 million dollars of stock when you only wanted to sell 1/2 a million. If your system is clever and checks the updates, it detects that another transaction has occurred after you started and prompts you. Hopefully this causes you to ring the customer and check whether they wanted to sell 1/2, 1 or 1 1/2 dollars of stock.
That's what Eddy was getting at.
This space for rent
|
|
|
|
|
Thanks, sorry may be I read him wrong. thanks for the neat explanation.
|
|
|
|
|
R1911 wrote: Mate, please don't mistake. But I'm not sure why your replies are consistently sarcastic.
They're not meant to be sarcastic, but I can see how they could come across like that.
Someone could have deleted the record you tried to update. How should the computer recover from that automagically, without resorting to assumptions about one of the two conflicting updates? How DO you update a record that no longer exists?
Depending on what you are doing, there should be *very little* chance ever for two users simultaneous working on the same recordset. A neat solution I've seen would open the forms in read-only mode when someone else was working on that record, including the time they opened it "for editing".
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Got it. thanks! And excuse the misread. 
|
|
|
|
|
You're welcome, and no problem; I know I'm not good with humans 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Please be very sure this is a real use case, it is often identified as a problem by management or an inexperienced developer as something that can/might happen but they have no real idea if the application requires this level of engineering.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Sure. thanks. I'll try to share a pic of what I originally thought.
|
|
|
|
|
IMO, we start with an empty database and then keep on adding the tables/procedures as needed by that sprint. We do not design entire database upfront. Assuming this to be true, will code first approach (except for data loss) would be quicker for developers? Or database first approach will also be fine depending on comfort level of person working?
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
Both should be fine providing you establish a good model for publishing migrations in advance. Don't find yourself requiring migrations without a pre-set strategy; that's long nights and extra downtime just waiting to happen.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
I am assuming by migration you are referring to database increments. I guess the sprints have to be planned in a way that DB changes are incremental instead of breaking changes as much as possible.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
For a Database-First approach, yes. For Code-First there is a system built into EF called Migrations which will attempt to update the database to match the new code models without corrupting it:
Code First Migrations - EF6 | Microsoft Docs
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Ah OK. Never used code first approach so wasn't aware of this. I feel at home when I can write my own scripts. However, I am not the one writing them this time so will leave it for others to decide. Thanks for help.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
Caveat - I have never used EF.
Code first always seems like a recipe for disaster to me and the thought of multiple developers managing your data structure just curls my toes in horror. Having seen what some senior developers can do to a normalised database I'd hate to see what a junior dev could do.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: Code first always seems like a recipe for disaster to me
I have used EF but never code first way. I don't like when the power is taken away from me. SQL scripts are powerful addiction you see. 
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
The day I think EF can write a better query or create a data structure better than I can I will quit, oh wait I have retired 
Old dogs and all that, I cut my teeth on TSQL and will never abdicate that job although I am uncomfortable with CTEs.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: your data structure just curls my toes in horror
Unless you get paid based on billable hours. Then it is gleeful laughter all the way to the bank.
|
|
|
|
|
lw@zi wrote: IMO, we start with an empty database and then keep on adding the tables/procedures as needed by that sprint
That is the claim.
Think about do you want to live in a house where first they built the door, then the living room, then the kitchen, but first they needed to move the door because the kitchen made that door impossible...
Not to mention of course in the above I mentioned nothing about electricity nor plumbing.
|
|
|
|
|
That is where a very well thought sprint plan comes in. One must spend a really good amount of time modularizing (yes, that is a word from now on) the application, understanding dependencies and then planning the sprint so we do not end up in situations like:
Oh I can't add this new not null column to table anymore unless I set a default value. But there is no default value. Plus I can simply recreate this single table because 20 other tables and my in-laws don't approve of it.
Still, there is a good chance of getting into troubles. Fortunately this is not for me to decide (sprint planning, that is).
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
