Hi All, A few changes to the SQL drivers. * Biggest change is there are now no longer any socket close/free functions in the driver API these are now all handled by talloc destructors. If you suspect sockets aren't being closed properly, run with the extra -x and it'll print out a message when the destructor is called. * All the drivers now (optionally) can provide an instantiate method to do their own config parsing. This method gets passed in the config sub section (if it exists) matching the driver name. So for sqlite it'd be sql { sqlite { <this section> } } This will let us do driver specific configuration. If there are any client side options for MySQL / PostgreSQL that are useful for tuning/debugging feel free to submit patches. * Sqlite code has been pretty much rewritten so it works for everything (not just clients), and a new set of schemas created for sqlite. Yes the S is for simple not standardised *sigh*. * The 'filename' config item in the main sql config (which specified where the sqlite db was) has been moved into the sqlite {} section (where it should have always been). * There's a new bootstrap config item for sqlite. If bootstrap is set, and the specified sqlite database doesn't exist, it'll be created, then the sql file specified by bootstrap will be split on ;\n and each statement executed in turn to create the schema for the boostrapped database. The idea is to ship with a working configuration for sqlipool, so the DHCP just works after you've configured the ranges. If you're writing example configurations/modules that depend on SQL for persistent storage, it'd probably be a good idea to use the sqlite driver and bootstrap the database/schema that's required, then the examples work out of the box, so long as you have sqlite available. -Arran