From: bill l. <cbi...@gm...> - 2008-08-02 23:42:36
|
Nikolay Samofatov wrote: > Hello, Bill, >>> Hi, All! >>> >>> 2.0 version of has added "Service Manager" functionality, in DSN >>> configuration. >>> One can backup, restore, analyze databases from there. Currently it >>> crashes if somebody tries to use it. >>> >>> I think that such functionality only bloats ODBC driver, increasing >>> complexity and maintenance burden. >>> Does anyone have any objections if we eradicate it from the tree (both >>> 2.0 branch and HEAD)? >>> > [cut] >> Now "sqlconfigdatasource" works for me very well and I don't want to lose it. If >> you have any problem on using it, please bring it out so that we may discuss how >> to fix it. >> > To me using SQLConfigDataSource API (which is ODBC DSN configuration > API) to do database backup looks like "scratching your right ear with > your left leg". > If one wants to do backup he can use native Services API calls - > service_attach, service_start, service_query, service_detach, or invoke > GBAK directly. > This is not that difficult. > > The particular problems with existing Services API support in ODBC > driver are as follows: > 1) Configuration dialog crashes if you click "Services" button, navigate > a few tabs, and hit "Close" button > 2) Services API via SQLConfigDataSource is non-portable and unreliable. > Client is supposed to use Global Named Semaphores, with pre-defined > names to communicate with the driver. > This is a Windows-only thing, and drivers from different threads or > processes may clash with each other. With this API design proper > handling of errors and output is difficult. > > You illustrate it yourself: > >> May be I'm lazy, I just call sqlconfigdatasource without setting up any >> semaphore or SQLInstallerError as your examples indicated. > > It appears you don't check for errors, don't check service output (for > warnings), and don't show progress of this potentially long-running > operation. > > However, for our purposes, it would be enough simply to remove > "Services" button from DSN configuration dialog. > This is inappropriate to have a GUI button which crashes application, > and spending time to maintain 200+ Kb of Services API related code in > ODBC driver seems like a waste of time to me. > > If I go forward with this minimalistic fix, you would still get your > GBAK API in SQLConfigDataSource. It doesn't hurt you for as long you > don't know about it and don't use it. > And if you, or somebody else really loves it, he can spend time > re-designing and re-implementing it, so it becomes reliable and portable. > For the record, SQLConfigDataSource is a standard odbc api and not a firebird specific feature. ms access odbc driver also implements this api and I use it on daily basis. If you just want to remove the gui frond-end part, I'm indifferent, I don't use that either. However I will not concur if SQLConfigDataSource itself is going to be removed just because some application programmers do not use it properly leading to crash. If you are not capable of maintaining it, just leave it as it is. regards, |