one db. many instances.

Hey im creating a small "inventory" application. But say If i were to distribute this to a warehouse company, they would in theory need two programs running. One in the back recieving area, and one in the front service desk. So they can both look at items, change them, and delete them.

For my app, all i did was right click and add a mdf db. For me to have the two programs share the db, I'll need to put a DB on a networked computer in the warehouse. Then I would need to edit my connection String.

Is that all there is to it?

That should do it.

Perhaps consider using a full fledged SQL Server instance on a central box, stored procedures, nolocks, and dealing with concurrencies.

Yea I think I might have to deal with the concurrency thing. I am not worried about security that much right now.

You can read this. http://msdn.microsoft.com/msdnmag/is...09/DataPoints/

Also, can I have your sa password? :afrog:

Thanks but im using LINQ :)

and sa pass?

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.

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.

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.

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.

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:

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.

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.

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.