Re: one db. many instances.
Re: one db. many instances.
Perhaps consider using a full fledged SQL Server instance on a central box, stored procedures, nolocks, and dealing with concurrencies.
Re: one db. many instances.
Yea I think I might have to deal with the concurrency thing. I am not worried about security that much right now.
Re: one db. many instances.
You can read this. http://msdn.microsoft.com/msdnmag/is...09/DataPoints/
Also, can I have your sa password? :afrog:
Re: one db. many instances.
Thanks but im using LINQ :)
and sa pass?
Re: one db. many instances.
Quote:
Originally Posted by masfenix
and sa pass?
Don't listen to the frog, he is trying to be an evenly balanced individual, which means he has to post equal parts sense and nonsense. SA stands for System Administrator, you can figure out the rest.
Re: one db. many instances.
Linq uses optimistic concurrency. You'll have a bit of work ahead of you if you want (and I assume this is so) to use pessimistic and keep locks on your rows.
Re: one db. many instances.
I've googled it but I cant find something that will explain it easily to me.
WHats optimisitic vs pessimistic. I dont want super advanced alogirthims, just something that will keep db updated, and not cause problems.
Re: one db. many instances.
The issue of locking and concurrency is huge!
There are many ways to handle it - what we like most is "don't worry about it" - let SQL do it automatically.
But to arrive at that level of confidence means you architect the system in a way that sharing is natural...
To have that kind of conversation you really need to tell us a lot more about what is being maintained - how it's maintained simultaneously - and we can all offer opinions on methods to avoid pitfalls, bad data and such.
Re: one db. many instances.
Quote:
Originally Posted by Shaggy Hiker
Don't listen to the frog, he is trying to be an evenly balanced individual, which means he has to post equal parts sense and nonsense
:lol: :lol: :lol:
Re: one db. many instances.
Quote:
Originally Posted by masfenix
I've googled it but I cant find something that will explain it easily to me.
WHats optimisitic vs pessimistic. I dont want super advanced alogirthims, just something that will keep db updated, and not cause problems.
In short, pessimistic concurrency means you lock everything you retrieve so no-one else can touch it as long as you're editing it. It's called pessimistic because you assume the worst. It ensures that no concurrency violations occur but it also means a lot of data will be inaccessible while you're editing it, even though only a small portion of it may actually change.
Optimistic concurrency means you don't lock anything and assume a best case scenario. Any user can access and change any data at any time. When you save your changes a concurrency violation occurs if the data in the database is not the same as it was when you retrieved it. It's then up to your app to decide what to do. You can either leave the data as it is and ignore your own changes, save your own data and lose the other changes or else merge the two sets of data in some way.
Pessimistic concurrency is easier to implement but means that users may often find that they cannot retrieve the data they want. Optimistic concurrency is more work to implement but generally provides the best user experience.
I really don't know how you can have searched and not found information on concurrency. I just searched MSDN for optimistic concurrency and got numerous hits. I also Googled optimistic concurrency and got various hits on MSDN and elsewhere, including some specific to ADO.NET. Where exactly were you searching? If you have a .NET question then MSDN should always be the first place you look.
Re: one db. many instances.
but im only 19 so i dont understand it sometimes. but i understand it now, so I'll keep it in mind. thanks
I am gonna look at msdn for code exmpales now, but i wonder if they have any with LINQ.
Re: one db. many instances.
The principles are the same whether you're using ADO.NET or LINQ. You save your changes and, if an exception is thrown that indicates a concurrency violation, then you decide on a course of action, edit your data as required and then save it again.
It's quite easy to test because you can very easily set up an application that gets the data once, then gets the data again, edits the second copy of the data and saves it, then edits the first copy and saves it. The second save will produce a concurrency violation because the data in the database will not match what was retrieved.