Re: [Firebird-devel] Build and install with a Raspberry Pi 4B
2021.12.08. 17:55 keltezéssel, Alex Peshkoff via Firebird-devel írta: Yep, we need something more generic here. Can you prepare PR? No, sorry. I don't know how, but the bigger problem is I don't know the good solution. Gabor Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Build and install with a Raspberry Pi 4B
On 12/8/21 18:06, Gabor Boros wrote: 2021.12.08. 14:23 keltezéssel, Gabor Boros írta: dirname: hiányzó operandus További információkért adja ki a(z) „dirname --help” parancsot. One problem what I found, the below commit not care about aarch64. Alex? :-) Yep, we need something more generic here. Can you prepare PR? Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Build and install with a Raspberry Pi 4B
2021.12.08. 14:23 keltezéssel, Gabor Boros írta: dirname: hiányzó operandus További információkért adja ki a(z) „dirname --help” parancsot. One problem what I found, the below commit not care about aarch64. Alex? :-) https://github.com/FirebirdSQL/firebird/commit/03978534018e65f2ca25189abb2b0c104f16ae0c Gabor Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Build and install with a Raspberry Pi 4B
Hi All, I try to build and install from the master branch with the 64bit version of the official OS (2021-10-30-raspios-bullseye-arm64). ./autogen.sh --prefix=/opt/firebird make After in the gen directory make -f Makefile.install tarfile Then try to install from the extracted tar.gz with install.sh. Firebird 5.0.0.335-Initial.aarch64 Installation Press Enter to start installation or ^C to abort Extracting install data dirname: hiányzó operandus További információkért adja ki a(z) „dirname --help” parancsot. dirname: hiányzó operandus További információkért adja ki a(z) „dirname --help” parancsot. Please enter new password for SYSDBA user: masterkey /opt/firebird/bin/gsec: error while loading shared libraries: libfbclient.so.2: cannot open shared object file: No such file or directory Fatal error running 'systemctl --quiet start firebird.service' - exiting The lib* symlinks created in the "/" directory. Gabor Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors
On 2021-12-08 10:13, Dmitry Yemanov wrote: 28.11.2021 14:45, Mark Rotteveel wrote: We don't have anything like this. Theoretically, we could extend IRecordSet with something similar (although it would also require a protocol change), but the question is whether it's really needed. Personally, I don't see it useful per se. If users want to know a number of rows, then perhaps an explicit getRowCount() method would be more useful (*). But AFAIU the Java API does not mention it. (*) not applicable to uni-directional cursors? The intent of the method is to report the position of the current row. The example it is abused by some to get the total size was just an illustration of why people would expect a value after requesting the last row. But the same would be a problem if people went to last, scrolled around and then want to know the current row position. I was thinking about providing both "current position" and "row count" information values for a cursor. Both are doable, however the former has some issues: 1) Adjustments due to prefetch should be taken into account at both client and server sides, thus complicating the code (information response buffer must be parsed, value received from the engine/server must be replaced with the adjusted one). 2) If used "with purpose", it may be requested by the client after every fetch, thus multiplying the round-trips and killing the prefetch benefits. So it could make sense to request the position (send op_info_cursor) internally after every op_fetch_scroll packet. As every fetch request may return multiple rows, sending many positions is unnecessary and only position of the first row could be returned. This puts additional requirements to the client-side protocol implementations. 3) "row count" makes it possible to know the position after fetchLast() and everything else could be calculated locally by the client library, thus making the server-supported "current position" totally unnecessary. Do I miss anything? Could we agree on having only "row count" returned via op_info_cursor and leaving "cursor position" (getRow() in Java API) up the connectivity library developers? That sounds doable, but I won't have time to really look and think about this until the weekend. I'll reply then if I have more concerns. Mark Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors
08.12.2021 13:49, Dimitry Sibiryakov wrote: Storing of fetched rows is unavoidable indeed but prefetch?.. Is it done in background or before returning of the first row to client even in embedded mode? The latter. But prefetch is done in small chunks, usually it does not hurt. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors
Dmitry Yemanov wrote 08.12.2021 10:54: For scrollable cursors, rows are prefetched and cached by the engine and thus the count can be easily returned. It has its cost, but generally it's unavoidable anyway for scrollable cursors. Storing of fetched rows is unavoidable indeed but prefetch?.. Is it done in background or before returning of the first row to client even in embedded mode? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors
08.12.2021 12:37, Tony Whyman wrote: It would also be very useful to get rowcount returned for unidirectional cursors if that was readily possible. At present, it is only possible to get an accurate count of the number of rows in a cursor after you have fetched all of them. It cannot be calculated without fetching all rows, even inside the engine. For scrollable cursors, rows are prefetched and cached by the engine and thus the count can be easily returned. It has its cost, but generally it's unavoidable anyway for scrollable cursors. However, prefetching uni-directional cursors in advance would be a huge overkill which nobody usually needs. So "row count" is likely to return zero or error for uni-directional cursors. However, if you desperately needs "row count" and ready to pay the price, then just open the cursor as scrollable and fetch only forward. The "row count" will be available automagically. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors
On 08/12/2021 09:13, Dmitry Yemanov wrote: 3) "row count" makes it possible to know the position after fetchLast() and everything else could be calculated locally by the client library, thus making the server-supported "current position" totally unnecessary. Do I miss anything? Could we agree on having only "row count" returned via op_info_cursor and leaving "cursor position" (getRow() in Java API) up the connectivity library developers? As long as row count can be returned this would work for IBX. In all other cases, it looks like it should be possible to compute the current row number client side. It would also be very useful to get rowcount returned for unidirectional cursors if that was readily possible. At present, it is only possible to get an accurate count of the number of rows in a cursor after you have fetched all of them. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors
28.11.2021 14:45, Mark Rotteveel wrote: We don't have anything like this. Theoretically, we could extend IRecordSet with something similar (although it would also require a protocol change), but the question is whether it's really needed. Personally, I don't see it useful per se. If users want to know a number of rows, then perhaps an explicit getRowCount() method would be more useful (*). But AFAIU the Java API does not mention it. (*) not applicable to uni-directional cursors? The intent of the method is to report the position of the current row. The example it is abused by some to get the total size was just an illustration of why people would expect a value after requesting the last row. But the same would be a problem if people went to last, scrolled around and then want to know the current row position. I was thinking about providing both "current position" and "row count" information values for a cursor. Both are doable, however the former has some issues: 1) Adjustments due to prefetch should be taken into account at both client and server sides, thus complicating the code (information response buffer must be parsed, value received from the engine/server must be replaced with the adjusted one). 2) If used "with purpose", it may be requested by the client after every fetch, thus multiplying the round-trips and killing the prefetch benefits. So it could make sense to request the position (send op_info_cursor) internally after every op_fetch_scroll packet. As every fetch request may return multiple rows, sending many positions is unnecessary and only position of the first row could be returned. This puts additional requirements to the client-side protocol implementations. 3) "row count" makes it possible to know the position after fetchLast() and everything else could be calculated locally by the client library, thus making the server-supported "current position" totally unnecessary. Do I miss anything? Could we agree on having only "row count" returned via op_info_cursor and leaving "cursor position" (getRow() in Java API) up the connectivity library developers? Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] op_crypt_key_callback during op_connect
> Enable AllowEncryptedSecurityDatabase in firebird.conf (on server side). Thanks. I realized I forgot about that few minutes ago. :) -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] op_crypt_key_callback during op_connect
On 12/7/21 17:52, Jiří Činčura wrote: Hi, How can I get op_crypt_key_callback during op_connect to test P15 (as I see in protocol.h (https://github.com/FirebirdSQL/firebird/blob/master/src/remote/protocol.h#L86))? My hope was that encrypting security database would do the trick, but even in this case I get op_cond_accept after sending op_connect. Enable AllowEncryptedSecurityDatabase in firebird.conf (on server side). Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
