Mateusz Loskot wrote:
Yes, but I can't think (now) about using SOCI with data source which doesn't support SQL as mechanism for operating data.
No problem with this. SOCI does not impose any interpretation on the query string, it might be whatever the backend/server understands. After all, a single stored procedure call isn't that much SQL specific, right? It's just the matter of statistics that all existing SOCI backends deal with SQL servers, but that is not a principle. If anybody jumps in with the backend for CSV files that use grep/sed parameters' syntax as the basis for the query language (for example), it will work just fine. Consider: session s("csv:///etc/protocols"); rowset<string> rs = (s.prepare << "1:*"); copy(rs.begin(), rs.end(), ...); where "1:*" is taken from the top of my head and would mean "first field from all rows". That would be the SOCI way to get the list of network protocols on your Linux machine. Anybody willing to submit a backend for this? ;-) (Warning: table joins are more tricky.) SOCI focuses on *relational data* - the query language doesn't really matter. That's why I'm a bit reluctant to use SQL in its name. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/