Hello, I'm pretty much a lurker on this list that loves to watch what is new coming out and learn from the discussions. A database library interests me a lot though, so for once, I have questions. 1. Transactions begin, commit, and rollback are provided. I did not see any comments in the docs of code to help keep this exception safe. Should the burden of exception safety be passed onto the library? One possibility is Begin returns a "Transaction," a proxy for a "Session," that has a commit function, and will call rollback in the destructor. A transaction proxy would give the impression that several independent proxies may exist, which I am not sure if that could be made accurate, but if not at least it is a thought. 2. Query Construction I read the rationale for not having a query construction syntax. To sum up my understanding of it: when working with DBAs it is good to have queries separate. For some of us hobbyists or for prototyping it might be nice, especially so we do not have to worry about syntax issues that are minor and wouldn't show up till runtime. If the query construction was built on top of taking strings then it would still allow for users to choose whether to use the query construction or to have the expressions stored in a file. This converting it to a string could even be used to easily stream out all of the expressions to a file to ease transition from a compiled version to a runtime file version for the DBAs One possibility is: sql << select("name", "salary").from(persons).where.("id = ",id), into(name), into(salary); Original (From webpage): sql << "select name, salary from persons where id = " << id, into(name), into(salary); The where clause could be templated to allow id to be whatever type (using stringstream or lexical_cast?) to provide simiilar behavior to the "<< id" Some improvements could include: *Setting up column objects: It would take a column name and what table it is from. 1) Could serve as a precondtion: That the column does exist in the table 2) Generate the from clause for you For example: Column personsName ("name", "persons"); Column personsSalary ("salary", "persons"); sql << select(personsName, personsSalary).where.("id = ",id), into(name), into(salary); *lambda like expressions for generating the where clause. It could then be simplified ... Column personsId ("id", "persons"); sql << select(personsName, personsSalary).where.(personsId == id), into(name), into(salary); With this, it could even be improved by tempaltizing the Columns for what type should be contained therein. Then the where clause expression generator could compare the template type of "personId" to "id" A potential complaint is that this makes it too easy to mix tables unintentionally. This is not meant as critisism or something to hold up a review, but suggestions for refining the API according to my limited understanding of code design and SOCI. Reasons for these to not work or improvements on these ideas are definetly welcome. Ed Page