Connect to a central db server
-
Hello. I am teaching myself more .NET, really love the technology. I've created a simple desktop application. Basically, its a database frontend for an inventory management system. The databse is simply an Access file (.mbd) which is in the same directory as the executable. In other words, my oleDbConnection objects look for the database (.mdb file) in the same directory. You see, this application will be independantly run on different PCs (each PC is in a different branch of our shop). I want to make all the different PCs share the same database. Ofcourse, the PCs will be connected (via LAN) to a central database server (where my .mbd file will be stored). In essence, all I want to do is make my application look for the .mbd file on the database server, instead of localdisk. However, there are some issues which I dont know how to address: 1) I guess the simplest way to achieve this is to create a shared network folder. But I dont think this solution is elegant... because it seems I have to hardcode the network path into the program (specifically, I have to hardcore the ConnectionString of the oleDbConnection object) 2) How do I keep the data synchronized? (ie, Race condition) The naive way to do this would be simply allow the database to throw an exception, and simply make the user "try again". But I want a more robust solution. In University, I learnt how to tackle race conditions in the same application using Semaphores, Monitors, etc. But I have no idea how to do it via networks.. since I am no longer dealing with Threads anymore. I would sincerely appreciate if someone could guide me in the right direction. I am sure there are well-establish methodologies for achieving this... a nudge in the right direction will help. A link, a book, anything.
-
Hello. I am teaching myself more .NET, really love the technology. I've created a simple desktop application. Basically, its a database frontend for an inventory management system. The databse is simply an Access file (.mbd) which is in the same directory as the executable. In other words, my oleDbConnection objects look for the database (.mdb file) in the same directory. You see, this application will be independantly run on different PCs (each PC is in a different branch of our shop). I want to make all the different PCs share the same database. Ofcourse, the PCs will be connected (via LAN) to a central database server (where my .mbd file will be stored). In essence, all I want to do is make my application look for the .mbd file on the database server, instead of localdisk. However, there are some issues which I dont know how to address: 1) I guess the simplest way to achieve this is to create a shared network folder. But I dont think this solution is elegant... because it seems I have to hardcode the network path into the program (specifically, I have to hardcore the ConnectionString of the oleDbConnection object) 2) How do I keep the data synchronized? (ie, Race condition) The naive way to do this would be simply allow the database to throw an exception, and simply make the user "try again". But I want a more robust solution. In University, I learnt how to tackle race conditions in the same application using Semaphores, Monitors, etc. But I have no idea how to do it via networks.. since I am no longer dealing with Threads anymore. I would sincerely appreciate if someone could guide me in the right direction. I am sure there are well-establish methodologies for achieving this... a nudge in the right direction will help. A link, a book, anything.
- Get away from Access. That is a piece of crap. Use SQL Server Express which will allow you to migrate your application to a full-blown SQL Server without programming changes. 2) You access the remote database with a connection string. This specifies which server to look for the database on. 3) You get away from hard coding (somewhat) by putting the connection string in your application config file. You may, however, make sure you are running the right version of Visual Studio to ensure you have the remote capabilities exposed to you. (Visual C# Express, for example, has a lot of functionality stripped from it.)