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
