Either:
const quince_postgresql::database db("localhost", "postgres", "postgres", "quincetest", "test");
or:
const quince_sqlite::database db("quincetest");
Either of the above definitions creates an object to represent the SQL database we are about to populate and query.
Creating the database object
doesn't create the SQL database. That is something you have to do outside
of quince, e.g. by using the PgAdminIII GUI tool (for PostgreSQL) or the
sqlite3.exe commandline tool (for sqlite). It may require special privileges.
Creating the database object
doesn't connect to the SQL database either. All it does is remember the
parameters for later, when quince makes connections. (This happens automatically
as needed.)
We'll go through all the constructor arguments (including those not used here) in detail later, but here are some things you might need to change straight away to suit your environment:
For the quince_postgresql::database
constructor:
localhost is the hostname
of the machine running the DBMS.
postgres
are, in order, the user name and password to give the server.
quincetest is the name
of the database that we'll be connecting to.
test is the name of
the default schema we'll be using. For the purposes of this chapter,
that's the schema where all our tables will be created.
For the quince_sqlite::database constructor:
quincetest is the name
of the database to use, which for sqlite is the name of the database
file.
All the string arguments to either database constructor are interpreted as UTF-8.
Now that we have a database object, the rest of our program will not mention PostgreSQL or sqlite. All our API calls will be to quince itself, not to the backend libraries.