Client-Server
-
Hi there! I'm new at .Net, and as I can see ADO.NET Does Not Depend On Continuously Live Connections. So how can I implement an Client-Server architecture? Imagine 2 clients updating the same record, theres a problem! Or not? Thanks a lot.:confused: <-- www.tiltxxi.com -->
-
Hi there! I'm new at .Net, and as I can see ADO.NET Does Not Depend On Continuously Live Connections. So how can I implement an Client-Server architecture? Imagine 2 clients updating the same record, theres a problem! Or not? Thanks a lot.:confused: <-- www.tiltxxi.com -->
You are not required to close the DB connection ... the fact that most ADO examples show that you should (1) open the DB, (2) set-up your objects, (3) do your query,update,insert,delete (4) close the DB connection ... does not mean you HAVE to do it that way ... You can open a DB connection and keep it open, there's nothing that says you cannot do this. Either way, true Client/Server means most, if not all, of your core logic exists server-side as Stored Procs, Triggers, Views (this is open to interpretation, I'm just trying to keep it simple). ADO is primaryily a Web based technology; at least, that seems to have been the primary focus by M$ behind ADO ... You can always use an OleDB connection and skip using ADO altogether. Just my two cents on this matter, D.
-
Hi there! I'm new at .Net, and as I can see ADO.NET Does Not Depend On Continuously Live Connections. So how can I implement an Client-Server architecture? Imagine 2 clients updating the same record, theres a problem! Or not? Thanks a lot.:confused: <-- www.tiltxxi.com -->
If two clients are updating the same record, then either: 1/ the order in which they update does not matter, or 2/ the order in which they update does matter - to the system. The first case is trivial. In the second case, the clients will have to communicate somehow between them to schedule who goes first and how the first guy tells the second when to go. That could be through any standard IPC mechanism. A record, after being fetched, is not locked for any purpose for any duration; even if you fetched it for the purpose of updating it.