Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

18.04.2017 17:13, Jiří Činčura wrote: > Hmm. Can you elaborate on that? Server doesn't determine real length of string in characters, so it just pad string up to 4*MaxChars bytes with spaces. That's why for CHAR(20) you always get 80 bytes of data, which can contain more that 20 characters

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

> See fixMetadata here in the Node.js driver. > > https://github.com/asfernandes/node-firebird-driver-native/blob/master/src/lib/fb-util.ts That's what I do exactly. But then I'm getting in length* full length of the field (as if it's CHAR) and not real length (as in VARCHAR). So for CHAR(20)

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

It's always going to be spaces/0s. I don't see a way for otherwise. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ On Tue, Apr 18, 2017, at 17:43, Dimitry Sibiryakov wrote: > 18.04.2017 17:38, Jiří Činčura wrote: > > So my best chance is probably to trim to length/4 and hope for

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

>CHAR and UTF-8 (generally, any variable character length charset) must >never be used > together. Hmm. Can you elaborate on that? Server allows that. And if developer creates such .NET UDR, I have to somehow handle it. Of course I can declare CHAR not supported at all, but that's kind

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

Hmm. That explains a lot of issues I was trying to push through today with CHARs. I.e. was getting 80 bytes buffer where was 20 characters and 60 spaces, because the characters were all 1B. It's pretty sad, actually. So my best chance is probably to trim to length/4 and hope for the best.

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

18.04.2017 16:52, Dmitry Yemanov wrote: > Generally it is, unless SQL_TEXT is of length 32766 or 32767. Isn't vary.vary_length declared as unsigned short? -- WBR, SD. -- Check out the vibrant tech community on

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

18.04.2017 17:03, Jiří Činčura wrote: > So for CHAR(20) UTF8 CHAR and UTF-8 (generally, any variable character length charset) must never be used together. -- WBR, SD. -- Check out the vibrant tech community

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

On 18-4-2017 17:20, Dimitry Sibiryakov wrote: > 18.04.2017 17:13, Jiří Činčura wrote: >> Hmm. Can you elaborate on that? > >Server doesn't determine real length of string in characters, so it just > pad string up > to 4*MaxChars bytes with spaces. That's why for CHAR(20) you always get 80 >

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

18.04.2017 17:23, Mark Rotteveel wrote: > Real length in characters of a CHAR is length / max bytes per character, > so for UTF-8: length / 4. But if you count real character in this buffer, you can get up to 80 of them. -- WBR, SD.

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

On 18/04/2017 12:38, Jiří Činčura wrote: > Hmm. That explains a lot of issues I was trying to push through today > with CHARs. I.e. was getting 80 bytes buffer where was 20 characters > and 60 spaces, because the characters were all 1B. > > It's pretty sad, actually. > > So my best chance is

[Firebird-devel] Start transaction from base transaction

Hi! In distributed systems there is a problem to use Firebird and maintains read consistency. Imagine follow situations: 1) A server (not database server) receives a request and dispatch it to others servers for extra processing and more than one server need to access the same database in a

Re: [Firebird-devel] Start transaction from base transaction

18.04.2017 19:28, Adriano dos Santos Fernandes wrote: > Hi! > > In distributed systems there is a problem to use Firebird and maintains > read consistency. > > Imagine follow situations: > > 1) A server (not database server) receives a request and dispatch it to > others servers for extra

Re: [Firebird-devel] Start transaction from base transaction

Adriano, > 1) A server (not database server) receives a request and dispatch it to others > servers for extra processing and more than one server need to access the > same database in a consistent way. > > 2) A multi-threaded program (may be a future version of gbak) wants to > dispatch

Re: [Firebird-devel] Start transaction from base transaction

On 18/04/2017 13:43, Vlad Khorsun wrote: >Some time ago there was discussion about sharing snapshots. As for me, it > is useful feature. Not a "must have", but useful. > >With current implementation of database snapshots (private copy of TIP) > it is not enough just to specify "base"

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

> Jiri, what you said (change SQL_TEXT to SQL_VARYING) and what I show you > (fixMetadata function) just fix this problem. I wish. See below. Also I have to investigate the 32766 or 32767 limit Dmitry Y. mentioned. I suppose he's not lying. :) That would make it suck even more. > Change it and

Re: [Firebird-devel] Start transaction from base transaction

On 18/04/2017 15:01, Vlad Khorsun wrote: > 18.04.2017 20:21, Adriano dos Santos Fernandes wrote: >> On 18/04/2017 13:43, Vlad Khorsun wrote: >>> Some time ago there was discussion about sharing snapshots. As for me, >>> it >>> is useful feature. Not a "must have", but useful. >>> >>> With

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

Hi Jiri, you must decode input UTF8 buffer into string(probably unicode) and next you have to trim trailing spaces. For text, just put some non US characters into text. Slavek > The length from metadata is 80. The memory dump where the pointer points > is: > { 80, 0, 49, 50, 51, 52, 53, 54, 55,

Re: [Firebird-devel] Start transaction from base transaction

18.04.2017 21:21, Adriano dos Santos Fernandes wrote: > On 18/04/2017 15:01, Vlad Khorsun wrote: >> 18.04.2017 20:21, Adriano dos Santos Fernandes wrote: >>> On 18/04/2017 13:43, Vlad Khorsun wrote: Some time ago there was discussion about sharing snapshots. As for me, it is

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

On 18/04/2017 15:35, Adriano dos Santos Fernandes wrote: > I just tested the UDR example wait_event declaring the SQL with CHAR(31) > and the function that uses VARCHAR just received the relevant length. I mean, it does not received 31 * 4, but received length 3 for string '123'. There is some

Re: [Firebird-devel] Start transaction from base transaction

18.04.2017 18:28, Adriano dos Santos Fernandes wrote: > 2) A multi-threaded program (may be a future version of gbak) wants to > dispatch simultaneous queries to Firebird, so need to use more than one > attachment and transaction and then do not have transaction consistency. I don't see

Re: [Firebird-devel] Start transaction from base transaction

> If you need simultaneous queries - make them possible, > what the point of transaction hacking? You want a single "view" of the database from multiple _connections_. There is nothing that provides this, today -- There is no way to ensure that all connections have that same view. Sean

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

> Yes, sure. Should changing the type be enough? Because I changed it from SQL_TYPE_DATE to SQL_TIMESTAMP, but I'm still getting length == 4, while the timestamp should be 8, isn't it? -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

> You should call setLength and setScale (if necessary) too. Ah, that's what I was missing. Isn't there a constant for i.e. SQL_TIMESTAMP? Because it's always 8 bytes, but feels wrong to hardcode it manually myself. Also going from SQL_TEXT to SQL_VARYING should be possible, right? How I'm going

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

18.04.2017 16:40, Jiří Činčura wrote: > Isn't there a constant for i.e. > SQL_TIMESTAMP? Because it's always 8 bytes, but feels wrong to hardcode > it manually myself. sizeof(ISC_TIMESTAMP) -- WBR, SD. -- Check

[Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

Hi *, in Plugin::makeProcedure I'm getting IRoutineMetadata and input and output builder. Can I use these, somehow, to change what values the server is going to send me later? I.e. calling getInputMetadata, changing types (in my case currently from SQL_TYPE_DATE to SQL_TIMESTAMP), then using

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

On 18/04/2017 11:15, Jiří Činčura wrote: > Hi *, > > in Plugin::makeProcedure I'm getting IRoutineMetadata and input and > output builder. Can I use these, somehow, to change what values the > server is going to send me later? I.e. calling getInputMetadata, > changing types (in my case currently

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

On 18/04/2017 11:27, Jiří Činčura wrote: >> Yes, sure. > Should changing the type be enough? Because I changed it from > SQL_TYPE_DATE to SQL_TIMESTAMP, but I'm still getting length == 4, while > the timestamp should be 8, isn't it? > You should call setLength and setScale (if necessary) too.

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

18.04.2017 17:40, Jiří Činčura wrote: > > Also going from SQL_TEXT to SQL_VARYING should be possible, right? Generally it is, unless SQL_TEXT is of length 32766 or 32767. Dmitry -- Check out the vibrant tech community

Re: [Firebird-devel] Start transaction from base transaction

Hello! 18.04.2017, 22:22, "Dimitry Sibiryakov" : I want to push data to another database as fast as possible, I want to have 5 connections walk the list of tables and read the rows and push them to the target DB.   With current Firebird architecture you won't get better

Re: [Firebird-devel] Start transaction from base transaction

18.04.2017 20:56, Leyne, Sean wrote: > You want a single "view" of the database from multiple _connections_. I still see no point for _multiple_ connections. Isn't one enough? > There is nothing that provides this, today -- There is no way to ensure that > all connections have that same

Re: [Firebird-devel] Start transaction from base transaction

18.04.2017 21:30, Leyne, Sean wrote: >>With current Firebird architecture - yes. It can be changed. > Really, then why have we been living with that @#$@#$@# limitation for more > than 10 years! Hmmm... Probably, because it is not limitation for real applications? Or because four

Re: [Firebird-devel] Start transaction from base transaction

18.04.2017 21:13, Leyne, Sean wrote: > I want to push data to another database as fast as possible, I want to have 5 > connections walk the list of tables and read the rows and push them to the > target DB. BTW, for such purpose Oracle have detached tablespaces. You detach such tablespace

Re: [Firebird-devel] Start transaction from base transaction

On 18/04/2017 16:41, Dimitry Sibiryakov wrote: > 18.04.2017 21:30, Leyne, Sean wrote: >>>With current Firebird architecture - yes. It can be changed. >> Really, then why have we been living with that @#$@#$@# limitation for more >> than 10 years! >Hmmm... Probably, because it is not

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

> This is some misuse or bug that requires a test case, because the > feature I described should work not only in external engines, but for > any query as the node driver shows in it test. I'm running it from Embedded now. I'll try tomorrow normal server. Shouldn't matter, but just in case.  Is

Re: [Firebird-devel] Start transaction from base transaction

18.04.2017 21:54, Adriano dos Santos Fernandes wrote: > But they need multi-processing and consistency. As a workaround for bad performance, no? -- WBR, SD. -- Check out the vibrant tech community on one of the

Re: [Firebird-devel] Start transaction from base transaction

18.04.2017 21:13, Leyne, Sean wrote: > No -- with a single connection only 1 SQL can be executed at a time -- > regardless of the number of threads to your process. With current Firebird architecture - yes. It can be changed. > Scenario: > > I want to push data to another database as fast as

Re: [Firebird-devel] Start transaction from base transaction

> > You want a single "view" of the database from multiple _connections_. > >I still see no point for _multiple_ connections. Isn't one enough? No -- with a single connection only 1 SQL can be executed at a time -- regardless of the number of threads to your process. Scenario: I want to

Re: [Firebird-devel] Start transaction from base transaction

>    With current Firebird architecture you won't get better performance from 5 > connections. > Dmitry Kouzmenko some time ago made a video that busted this myth. > > Nope, video was about inserts in multiple connections into one table. This is > - > yes, useless. 1 connection inserts all this

Re: [Firebird-devel] Start transaction from base transaction

> On 18/04/2017 16:41, Dimitry Sibiryakov wrote: > > 18.04.2017 21:30, Leyne, Sean wrote: > >>>With current Firebird architecture - yes. It can be changed. > >> Really, then why have we been living with that @#$@#$@# limitation for > more than 10 years! > >Hmmm... Probably, because it is