Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
On 10/12/17 13:06, Dimitry Sibiryakov wrote: 12.10.2017 11:55, Alex Peshkoff via Firebird-devel wrote: Suggested implementation of that possibilities is also bad - it's supposed to have different behavior depending upon text in parameter. You didn't see implementation, how can you appraise it? Your suppose is wrong. I do not mean code - I mean change of behavior of old API function in unstable way. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
12.10.2017 11:55, Alex Peshkoff via Firebird-devel wrote: Suggested implementation of that possibilities is also bad - it's supposed to have different behavior depending upon text in parameter. You didn't see implementation, how can you appraise it? Your suppose is wrong. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
On 10/12/17 12:02, Dimitry Sibiryakov wrote: 12.10.2017 10:24, Alex Peshkoff via Firebird-devel wrote: what problem do you want to solve with this change? No problem to solve. It is not bug fix, it is an improvement. It open new possibilities for app developers, nothing more. That possibilities appear to be suspicious (I know it's rather hard to estimate - but estimation from me and Vlad match). Suggested implementation of that possibilities is also bad - it's supposed to have different behavior depending upon text in parameter. We can't accept that improvement. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
12.10.2017 10:24, Alex Peshkoff via Firebird-devel wrote: what problem do you want to solve with this change? No problem to solve. It is not bug fix, it is an improvement. It open new possibilities for app developers, nothing more. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
12.10.2017 0:32, Vlad Khorsun via Firebird-devel wrote: I mixed ? It is you, who offer to use auth params as actions params ! No, I don't. Currently, developer have single place to set action's database name. You offer to set it here and there - this is confusing at least and solves no problem. Not quite so: it hides a big security hole. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
Well Dmitry (and please briefly) - what problem do you want to solve with this change? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
12.10.2017 0:37, Dimitry Sibiryakov wrote: 11.10.2017 22:56, Vlad Khorsun via Firebird-devel wrote: The problem is that you don't undestand that auth parameters (required to create connection) should not be mixed with action's parameters. I can't understand what you talking about. Action parameters are in spb at isc_service_start() call. Sure Auth parameters are in spb parameters at isc_service_attach() call. Exactly Where you mixed them? I mixed ? It is you, who offer to use auth params as actions params ! Where have you found this limit? What word from my message you read as "isc_svc_db_name cannot be used in spb anymore"? So, do you offer engine to add all params from isc_service_attach's SPB into isc_service_start's SPB ? No. Try to re-read word by word: --- README.services_extension - 8) Services API extension - passing database connection string as a service manager name. (Dmitry Sibiryakov, 2017) When database connection string is used in call isc_service_attach() or as the first parameter of fbsvcmgr utility, this database is used as a default value for "expected_db". And expected db become a default value for "dbname". If "expected_db" or "dbname" tags are specified explicitly, defaults have no effect. Old service names are still recognized, so this feature cannot be used with databases named like "service_mgr", "backup", "anonymous", etc. This is substitution of one entity (*action* parameters) by another one (*auth* params). This is hack, as for me. Currently, developer have single place to set action's database name. You offer to set it here and there - this is confusing at least and solves no problem. Vlad -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
11.10.2017 22:56, Vlad Khorsun via Firebird-devel wrote: The problem is that you don't undestand that auth parameters (required to create connection) should not be mixed with action's parameters. I can't understand what you talking about. Action parameters are in spb at isc_service_start() call. Auth parameters are in spb parameters at isc_service_attach() call. Where you mixed them? Where have you found this limit? What word from my message you read as "isc_svc_db_name cannot be used in spb anymore"? So, do you offer engine to add all params from isc_service_attach's SPB into isc_service_start's SPB ? No. Try to re-read word by word: --- README.services_extension - 8) Services API extension - passing database connection string as a service manager name. (Dmitry Sibiryakov, 2017) When database connection string is used in call isc_service_attach() or as the first parameter of fbsvcmgr utility, this database is used as a default value for "expected_db". And expected db become a default value for "dbname". If "expected_db" or "dbname" tags are specified explicitly, defaults have no effect. Old service names are still recognized, so this feature cannot be used with databases named like "service_mgr", "backup", "anonymous", etc. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
11.10.2017 23:33, Dimitry Sibiryakov wrote: 11.10.2017 22:14, Vlad Khorsun via Firebird-devel wrote: IIRC, it is already implemented. No. This functionality is in fbsvcmgr, but not in gbak. It is implemented at Service API level, i.e. by all the providers (engine, remote, etc) but used not by all utilities (gbak), yes. And i still see no relation with subject. And currently it is rather hack with magic word "stdout" instead of proper implementation. Can't say that current way with "stdout" is perfect, but i'm really afraid of your vision of "proper implementation", sorry So, turn your imagination on. Service *is not a database*, is it clear ? Service could make any kind of job, it is not bound to any database. Yes. If it does not need dbname, it won't get dbname. What's the problem? The problem is that you don't undestand that auth parameters (required to create connection) should not be mixed with action's parameters. A little for you to know: isc_service_attach() and isc_service_start() is different routines and requires different set of params. More, you may call isc_service_start() many times within the same service connection, AFAIU, and i see no reason to limit all the service tasks by the same database. Where have you found this limit? What word from my message you read as "isc_svc_db_name cannot be used in spb anymore"? So, do you offer engine to add all params from isc_service_attach's SPB into isc_service_start's SPB ? Is it really good ? You didn't read what I wrote. As usual. OMG. Write something more interesting next time, pls fbsvcmgr.exe host:service_mgr action_nbak dbname employee nbk_file employee.bak nbk_level 0 fbsvcmgr.exe host:employee action_nbak nbk_file employee.bak nbk_level 0 And what is the best: both these commands works and do exactly the same. No old functionality is broken or changed. So why do you need second one if it the same as first ? To save few pressing of keyboard ? No, not to save pressing of keyboards. To save app developer a lot of time he must waste on transforming database connection string into service connection string. Lot of time ? Are you kidding ??? I already told you that hiding one entity by another one is very bad idea. Subject is not just hiding. One entity must simply die as completely unnecessary and having no purpose. But not right now. For awhile it still can be here as fifth wheel. RTFM: isc_service_attach() and isc_service_start() Vlad -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
11.10.2017 22:14, Vlad Khorsun via Firebird-devel wrote: IIRC, it is already implemented. No. This functionality is in fbsvcmgr, but not in gbak. And currently it is rather hack with magic word "stdout" instead of proper implementation. So, turn your imagination on. Service *is not a database*, is it clear ? Service could make any kind of job, it is not bound to any database. Yes. If it does not need dbname, it won't get dbname. What's the problem? A little for you to know: isc_service_attach() and isc_service_start() is different routines and requires different set of params. More, you may call isc_service_start() many times within the same service connection, AFAIU, and i see no reason to limit all the service tasks by the same database. Where have you found this limit? What word from my message you read as "isc_svc_db_name cannot be used in spb anymore"? You didn't read what I wrote. As usual. fbsvcmgr.exe host:service_mgr action_nbak dbname employee nbk_file employee.bak nbk_level 0 fbsvcmgr.exe host:employee action_nbak nbk_file employee.bak nbk_level 0 And what is the best: both these commands works and do exactly the same. No old functionality is broken or changed. So why do you need second one if it the same as first ? To save few pressing of keyboard ? No, not to save pressing of keyboards. To save app developer a lot of time he must waste on transforming database connection string into service connection string. I already told you that hiding one entity by another one is very bad idea. Subject is not just hiding. One entity must simply die as completely unnecessary and having no purpose. But not right now. For awhile it still can be here as fifth wheel. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
11.10.2017 22:22, Dimitry Sibiryakov wrote: 11.10.2017 20:57, Vlad Khorsun via Firebird-devel wrote: I don't understand your speculations Ok, turn your imagination on: Performance of gbak must be improved by feeding of backup stream from server using services instead of sending queries. How will you implement it? IIRC, it is already implemented. And i see no relation with a way to set connection string here. If you need to implement new service action - define it parameters, as usual, and implement it. Where the problem ? Because someone at IB times made decision that service connections is not a database connection. And i must agree that service could work with some database. Another service could work with two databases and third service could work with no database at all (read firebird.log, for example). As expirienced user of ISC API you should know it. No, I have no idea what service can work with two databases. Currently there is no one able to do that. Even multifile restore is impossible with using of services. So, turn your imagination on. Service *is not a database*, is it clear ? Service could make any kind of job, it is not bound to any database. Every service action have set of parameters. In your second example i see no paramenter for action action_db_stats. This is not that kind of simplicity that i would ask for. action_db_stats requires no parameters. It needs to set database name to gather stats from. Since Firebird is a DBMS (note first letter), many services works with databases (surprize) and uses some common parameters for its actions. But it doesn't mean that action_db_stats requires no parameters. A little for you to know: isc_service_attach() and isc_service_start() is different routines and requires different set of params. More, you may call isc_service_start() many times within the same service connection, AFAIU, and i see no reason to limit all the service tasks by the same database. I used it as the shortest example. If you insist on longer one, here it is. Compare fbsvcmgr.exe host:service_mgr action_nbak dbname employee nbk_file employee.bak nbk_level 0 fbsvcmgr.exe host:employee action_nbak nbk_file employee.bak nbk_level 0 And what is the best: both these commands works and do exactly the same. No old functionality is broken or changed. So why do you need second one if it the same as first ? To save few pressing of keyboard ? And you consider it as "technical" reason to fool app devs ? To finish with it: you make proposal and ask for objections, i gave you objections, what else do you want ? If you forgot: I would like to hear technical problems that you foresee with proposed changes, not "I'm fine with current way, no need to improve anything". I already told you that hiding one entity by another one is very bad idea. And there is no improvement in your proposal. And you don't read what i wrote. As expected. Vlad -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
11.10.2017 21:27, Alex Peshkoff via Firebird-devel wrote: Possible - if you use isc_sbp_command_line. Dirty hack, but still working. There is service that can work with multiple databases - trace. So, this service won't gain anything from new possibilities. I see no problem with that. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
On 10/11/17 22:22, Dimitry Sibiryakov wrote: 11.10.2017 20:57, Vlad Khorsun via Firebird-devel wrote: I don't understand your speculations Ok, turn your imagination on: Performance of gbak must be improved by feeding of backup stream from server using services instead of sending queries. How will you implement it? Because someone at IB times made decision that service connections is not a database connection. And i must agree that service could work with some database. Another service could work with two databases and third service could work with no database at all (read firebird.log, for example). As expirienced user of ISC API you should know it. No, I have no idea what service can work with two databases. Currently there is no one able to do that. Even multifile restore is impossible with using of services. Possible - if you use isc_sbp_command_line. There is service that can work with multiple databases - trace. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
11.10.2017 20:57, Vlad Khorsun via Firebird-devel wrote: I don't understand your speculations Ok, turn your imagination on: Performance of gbak must be improved by feeding of backup stream from server using services instead of sending queries. How will you implement it? Because someone at IB times made decision that service connections is not a database connection. And i must agree that service could work with some database. Another service could work with two databases and third service could work with no database at all (read firebird.log, for example). As expirienced user of ISC API you should know it. No, I have no idea what service can work with two databases. Currently there is no one able to do that. Even multifile restore is impossible with using of services. Every service action have set of parameters. In your second example i see no paramenter for action action_db_stats. This is not that kind of simplicity that i would ask for. action_db_stats requires no parameters. I used it as the shortest example. If you insist on longer one, here it is. Compare fbsvcmgr.exe host:service_mgr action_nbak dbname employee nbk_file employee.bak nbk_level 0 fbsvcmgr.exe host:employee action_nbak nbk_file employee.bak nbk_level 0 And what is the best: both these commands works and do exactly the same. No old functionality is broken or changed. To finish with it: you make proposal and ask for objections, i gave you objections, what else do you want ? If you forgot: I would like to hear technical problems that you foresee with proposed changes, not "I'm fine with current way, no need to improve anything". -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
11.10.2017 21:34, Adriano dos Santos Fernandes wrote: I must agree that host:service_mgr is weird, but not all services expects (or would expect) a database. Can't say it is weird. Probably, we could allow to skip service manager name, but it will be hard to specify XNET protocol without it. I.e. now we could use xnet://sevice_mgr. And, of course, i agree with you that service could expect no or more than one database name. Regards, Vlad -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
11.10.2017 21:09, Dimitry Sibiryakov wrote: 11.10.2017 19:47, Vlad Khorsun via Firebird-devel wrote: I don't see it as a problem, as user already should understand what is connection string and how to construct is from host name and database name. From my expirience "usual" applications (such as accounting etc) already hide details about connection string from end users. Tools for developers, on the contrary, allows to set connection string (among other params), but developers should understand what is a host name, database name and service manager name. So, i see no problem here. Ok. To make gbak getting backup stream from service for performance purpose you suggest to change command line options from current "gbak " to "gbak " and tell all users that they should understand it, right? I don't understand your speculations I.e. users will ask you for new version of application, good for you, isn't is ? No, it isn't. At that point I may be already dead. There is service connection and there is database connection. This is different things. Why they must be different? Services are not goal, it just a tool for working with databases. Even with the same connection string, they use different API. Isn't this difference more than enough? Because someone at IB times made decision that service connections is not a database connection. And i must agree that service could work with some database. Another service could work with two databases and third service could work with no database at all (read firebird.log, for example). As expirienced user of ISC API you should know it. Your proposal hides the difference and just fools app devs. I would say that it makes using of API simpler. I can't say that currently it is hard to use and requires such simplification. I see no benefits, just attempt to make a bit complex thing more complex and ambiguous. Compare this: fbsvcmgr host:service_mgr user sysdba password xxx expected_db employee action_db_stats dbname employee and this: fbsvcmgr host:employee user sysdba password xxx action_db_stats What is "more complex and ambiguous"? Every service action have set of parameters. In your second example i see no paramenter for action action_db_stats. This is not that kind of simplicity that i would ask for. Perhaps, you must start to use services API to feel the benefits. As do I. Sometime, when you speak for another person, it is so funny To finish with it: you make proposal and ask for objections, i gave you objections, what else do you want ? Vlad -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
On 11/10/2017 15:09, Dimitry Sibiryakov wrote: > > Compare this: > > fbsvcmgr host:service_mgr user sysdba password xxx expected_db > employee action_db_stats dbname employee > > and this: > > fbsvcmgr host:employee user sysdba password xxx action_db_stats > > What is "more complex and ambiguous"? > I must agree that host:service_mgr is weird, but not all services expects (or would expect) a database. Adriano -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
10.10.2017 19:00, Dimitry Sibiryakov wrote: Hello. Imagine that you are an application developer and develop an application that allow users to enter connection string for database they want to work with. Imagine that in new version of the application you would like to add some work with services (backup, restore, stats, etc.) What options do you have to make a string that can be used in isc_service_attach() call? 1) Ask user to enter host name and database name separately then combine the string in form :service_mgr; 2) Parse database connection string entered by user to get host name. First option has backward compatibility problem because in previous version of the application you asked only for whole connection string. I don't see it as a problem, as user already should understand what is connection string and how to construct is from host name and database name. From my expirience "usual" applications (such as accounting etc) already hide details about connection string from end users. Tools for developers, on the contrary, allows to set connection string (among other params), but developers should understand what is a host name, database name and service manager name. So, i see no problem here. Second option has forward compatibility problem because in new versions of Firebird format of connection string can be changed. I.e. users will ask you for new version of application, good for you, isn't is ? I'd suggest to offer to the application developer third, more convenient, option: subj. There is service connection and there is database connection. This is different things. Your proposal hides the difference and just fools app devs. If database connection string is used this way, server can automatically set the database name to expected_db and dbname tags if they are not provided explicitly. isc_spb_expected_db was introduced for another purposes and looks like kind of hack for me. I.e. instead of "fbsvcmgr.exe localhost:service_mgr -action_nbackup -dbname test -nbk_level 0 -nbk_file file.nbk" one could use "fbsvcmgr.exe localhost:test -action_nbackup -nbk_level 0 -nbk_file file.nbk". Opinions? I see no benefits, just attempt to make a bit complex thing more complex and ambiguous. Vlad -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
11.10.2017 16:08, Vlad Khorsun via Firebird-devel wrote: PS if this message will pass to the list, i'll explain why i object I know why you object, but I would like to hear what technical problems you foresee with this feature. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
11.10.2017 16:59, Dimitry Sibiryakov пишет: 10.10.2017 18:00, Dimitry Sibiryakov wrote: I'd suggest to offer to the application developer third, more convenient, option: subj. If database connection string is used this way, server can automatically set the database name to expected_db and dbname tags if they are not provided explicitly. I.e. instead of "fbsvcmgr.exe localhost:service_mgr -action_nbackup -dbname test -nbk_level 0 -nbk_file file.nbk" one could use "fbsvcmgr.exe localhost:test -action_nbackup -nbk_level 0 -nbk_file file.nbk". Opinions? If nobody objects, I'll create a ticket and PR. I object it. Vlad PS if this message will pass to the list, i'll explain why i object -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using ordinary database connection string in isc_service_attach() call
10.10.2017 18:00, Dimitry Sibiryakov wrote: I'd suggest to offer to the application developer third, more convenient, option: subj. If database connection string is used this way, server can automatically set the database name to expected_db and dbname tags if they are not provided explicitly. I.e. instead of "fbsvcmgr.exe localhost:service_mgr -action_nbackup -dbname test -nbk_level 0 -nbk_file file.nbk" one could use "fbsvcmgr.exe localhost:test -action_nbackup -nbk_level 0 -nbk_file file.nbk". Opinions? If nobody objects, I'll create a ticket and PR. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Using ordinary database connection string in isc_service_attach() call
Hello. Imagine that you are an application developer and develop an application that allow users to enter connection string for database they want to work with. Imagine that in new version of the application you would like to add some work with services (backup, restore, stats, etc.) What options do you have to make a string that can be used in isc_service_attach() call? 1) Ask user to enter host name and database name separately then combine the string in form :service_mgr; 2) Parse database connection string entered by user to get host name. First option has backward compatibility problem because in previous version of the application you asked only for whole connection string. Second option has forward compatibility problem because in new versions of Firebird format of connection string can be changed. I'd suggest to offer to the application developer third, more convenient, option: subj. If database connection string is used this way, server can automatically set the database name to expected_db and dbname tags if they are not provided explicitly. I.e. instead of "fbsvcmgr.exe localhost:service_mgr -action_nbackup -dbname test -nbk_level 0 -nbk_file file.nbk" one could use "fbsvcmgr.exe localhost:test -action_nbackup -nbk_level 0 -nbk_file file.nbk". Opinions? -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
