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.