Re: [Firebird-devel] isc_usrname_too_long
On 1/14/22 18:41, Dimitry Sibiryakov wrote: Hello All. Shouldn't subj text to be corrected? Also shouldn't it to be returned if user name received in DPB (after conversion into UTF-8) doesn't fit as well? Better mark set of isc_add/modify/delete_user() functions deprecated. That's the only place where subj is used. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_usrname_too_long
Mark Rotteveel wrote 14.01.2022 17:21: Also when you use a DPB v2, it is wide, so accepts far larger values than you'll ever logically need for a user name. The only problem that fbclient doesn't use it during conversion from user-provided DPB into sent-to-server DPB and in server user name is limited to 63 characters anyway. (Though I'm not sure if it is ever checked there.) -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_usrname_too_long
On 14-01-2022 17:10, Dimitry Sibiryakov wrote: Mark Rotteveel wrote 14.01.2022 17:06: Also shouldn't it to be returned if user name received in DPB (after conversion into UTF-8) doesn't fit as well? I'm not sure what you mean with that. Currently if someone put into DPB non-ASCII user name and during conversion into UTF-8 it doesn't fit 255 bytes the error "attempt to store %d bytes in a clumplet with maximum size 255 bytes" is thrown. Shouldn't the error to be a little more specific and comprehensive...? Personally, I don't think so, as I think that is messy to conflate logic for populating the DPB with selecting appropriate messages specific to the select DPB item. Also when you use a DPB v2, it is wide, so accepts far larger values than you'll ever logically need for a user name. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_usrname_too_long
Mark Rotteveel wrote 14.01.2022 17:06: Also shouldn't it to be returned if user name received in DPB (after conversion into UTF-8) doesn't fit as well? I'm not sure what you mean with that. Currently if someone put into DPB non-ASCII user name and during conversion into UTF-8 it doesn't fit 255 bytes the error "attempt to store %d bytes in a clumplet with maximum size 255 bytes" is thrown. Shouldn't the error to be a little more specific and comprehensive...? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_usrname_too_long
On 14-01-2022 16:41, Dimitry Sibiryakov wrote: Hello All. Shouldn't subj text to be corrected? I probably should. Also shouldn't it to be returned if user name received in DPB (after conversion into UTF-8) doesn't fit as well? I'm not sure what you mean with that. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] isc_usrname_too_long
Hello All. Shouldn't subj text to be corrected? Also shouldn't it to be returned if user name received in DPB (after conversion into UTF-8) doesn't fit as well? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Remove blr_parameter3
Hi! Our code does not generate blr_parameter3. I propose to remove this code, commenting this verb for not immediate reuse. It looks like as it tries to put in the third parameter slot the maximum string length moved to the parameter. Do anyone has some background about this? Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Batch completion state's simplified error blocks
I can replicate it even with native code with 4.0.1.2704 fbclient (and same server). I'll create GitHub issue. -- 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] Batch completion state's simplified error blocks
Sending 66 messages with error the response is: statement handle: 2 p_batch_reccount: 66 p_batch_updates: 66 p_batch_vectors: 64 p_batch_errors: 2 And again not a single integer in buffer for p_batch_errors. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Batch completion state's simplified error blocks
Hi *, It looks like server is not sending data according to description for op_batch_cs. I get this: statement handle: 2 p_batch_reccount: 65 p_batch_updates: 65 p_batch_vectors: 64 p_batch_errors: 1 Which makes sense (I've sent 65 messages with error). Then I read 65 integers for p_batch_updates, then 64 (int, status vector) pairs for p_batch_vectors. Finally I want to read one integer for p_batch_errors, but there's nothing left in input network buffer. Did I miss something? -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
