2

I was wondering what is the exact difference between a client-server and a standalone application, particularly in following scenario.

For example lets say there is a win forms application running on a PC. So that the DBMS, SQL Server also installed on the same PC as it hosts the database too. Now this is clearly a standalone setup.

Now if we introduce another PC and connect it to the first PC through a local area network and we want to run the application on this new PC too but it will use the same database which is in the first PC.

Now is this application considered to be a standalone app or a thick client - server?

EDIT: The application communicates with SQL server to access data and processing will happen locally. SQL server hosts the data and there are few stored procedures and views too.

Improve this question

1 Answer 1

Reset to default
5

Most client-server applications can be installed in a "standalone setup", where the client and server machine are the same, as you wrote, but that does not make them a "standalone application". Such a system is still a client/server application, and the interprocess communication between the client application process and the database process will typically happen through a network protocol like TCP/IP. Also, installation and administration typically require almost the same effort as on two separate machines.

Of course, applications specificially made for "standalone usage" are typically optimized for that scenario, for example, by accessing the database directly from the client application process, which eliminates the need for (typically slower) interprocess communication. Or they have still two processes for client app and database, but those communicate by using "shared memory", which (on most operating system, see here for execeptions) supports only non-distributed scenarios. This makes the applications more lightweight and easier to install or administer, but you cannot easily connect to that database from a second PC.

Of course, lots of DB systems (like SQL Server) are smart enough to use TCP/IP for a connection to a another machine, and switch to shared memory automatically when they detect client and server beeing on the same machine. I would still call such a system a client/server application.

As an example in the context of Microsoft Databases, there is SQL Server Compact Edition which is specifially made for such standalone applications, but not for client/server usage. A very popular example from the freeware world is SqLite. And if you are looking for a full-featured relational database system which can switch between a "stand alone mode" (using shared memory, but easy to install without a background service) and "client server mode" (using TCP/IP) I would recommend SQL Anywhere.

Improve this answer
6
  • So that the scenario explained in the question is actually a client server application (a thick client) which is in a Standalone setup as my DBMS is SQL Server Express edition(2008) Am I correct? Note that the application is .net
    – CAD
    Jul 12, 2014 at 10:09
  • 1
    @Chathuranga: Yes, I think so (and AFAIK SQL Server Express is a client/server database, opposed to SQL Server CE), but this ".NET" remark has nothing to do with what I wrote. But what is the real world problem you want to solve by discussing this terms? How you call you application does not make a difference of what the architecture is capable of, right?
    – Doc Brown
    Jul 12, 2014 at 10:12
  • Sorry to bother you asking sort of a beginner level questions. For it to be a inter-process communication between the client application process and the database process, don't we have to connect the application to the database server through a ODBC connection? If we directly connect the application to the SQL sever instance through the IDE (by the connection string) still its a kind of a inter-process communication?
    – CAD
    Jul 12, 2014 at 10:21
  • Actually I've developed an application the way I've mentioned. So now I just want to do a technical documentation where I have to discus the architecture.
    – CAD
    Jul 12, 2014 at 10:25
  • 2
    @Chathuranga: you are mixing up the programming interface (like ODBC or ADO.NET) with the underlying communication protocol. For example, using ADO.NET for SQL Server CE will always cause in-process communication (automatically in the background). Connecting to MS Sql server will typically use TCP/IP, though according to this link stackoverflow.com/questions/1587036/…, the provider switches automatically to shared memory when connecting to a local system. Though, I would not call the latter a "standalone application" just for this behaviour.
    – Doc Brown
    Jul 12, 2014 at 11:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.