> 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.
You can't trim all trailing spaces. You need to know the length.
But even that is wrong, because I should get it as SQL_VARYING pr
19.04.2017 1:09, Leyne, Sean wrote:
> Please stay on point
>
> How would detaching tablespace provide any solution to the use case, I am
> referring to??
>
> The tables I want to access would be "live" with activity from other
> connections!
The same way as you now access whole "l
18.04.2017 18: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.
As in Sean's scenario: you pumped data into 5 tables via 5 connections using
5 derived
transactions. Now you need atomically
On 19/04/2017 03:33, Jiří Činčura wrote:
>> I'm running it from Embedded now. I'll try tomorrow normal server.
>> Shouldn't matter, but just in case.
> Shouldn't, but does. Using server I get correct lengths, but using
> embedded I always get 4*length (when using parameter, of course).
>
Very stra
19.04.2017 11:51, Dimitry Sibiryakov пишет:
> 18.04.2017 18: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.
>
> As in Sean's scenario: you pumped data into 5 tables via 5 connections
19.04.2017 12:23, Vlad Khorsun wrote:
>> As in Sean's scenario: you pumped data into 5 tables via 5 connections
>> using 5 derived
>> transactions. Now you need atomically commit all these transactions in all
>> connections.
>> How would you do it?
>I don't. As there was no such requireme
> Very strange. My test with UDR was with embedded.
>
> Even more strange because external procedures and remote/embedded layer
> has nothing related.
I tried padding the CHAR with different character than 32 (space) - to
see whether it changes on plugin part as well -, but that didn't work.
It w
On 19/04/2017 07:43, Jiří Činčura wrote:
> I can create some sample for you, if you want. Then you can drop in your
> own fbclient.dll and attach debugger or something like that.
>
It would be very good, specially if it works in Linux (.NET Core?).
Adriano
--
> It would be very good, specially if it works in Linux (.NET Core?).
.NET Core does not have a support for C++/CLI yet (if ever), so it's a
full .NET, thus Windows only. Would that work for you?
--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/
--
19.04.2017 13:34, Dimitry Sibiryakov wrote:
> 19.04.2017 12:23, Vlad Khorsun wrote:
>>> As in Sean's scenario: you pumped data into 5 tables via 5 connections
>>> using 5 derived
>>> transactions. Now you need atomically commit all these transactions in all
>>> connections.
>>> How would you
19.04.2017 13:43, Jiří Činčura wrote:
>> Very strange. My test with UDR was with embedded.
>>
>> Even more strange because external procedures and remote/embedded layer
>> has nothing related.
>
> I tried padding the CHAR with different character than 32 (space) - to
> see whether it changes on pl
On 19/04/2017 07:53, Jiří Činčura wrote:
>> It would be very good, specially if it works in Linux (.NET Core?).
> .NET Core does not have a support for C++/CLI yet (if ever), so it's a
> full .NET, thus Windows only. Would that work for you?
>
In this case, it would be faster for both of us if you
19.04.2017 12:57, Vlad Khorsun wrote:
>Sean speak about *read* consistency within few transactions\connections to
> the same
> database. No more, no less.
Ok. What advantages can have derived transactions over array DML +
asynchronous queries
which are more versatile?
--
WBR, SD.
The revoke statement fails
--
Key: CORE-5523
URL: http://tracker.firebirdsql.org/browse/CORE-5523
Project: Firebird Core
Issue Type: Bug
Affects Versions: 3.0.2
Environment: Windows 10, firebird 3.0 and f
> In this case, it would be faster for both of us if you just sent some
> (non-buildable) relevant pieces of code for now and I try to reproduce
> with UDR or FB/Java.
Sent in private email, with attachments.
--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/
-
19.04.2017 14:03, Dimitry Sibiryakov wrote:
> 19.04.2017 12:57, Vlad Khorsun wrote:
>> Sean speak about *read* consistency within few transactions\connections
>> to the same
>> database. No more, no less.
>
> Ok. What advantages can have derived transactions over array DML +
> asynchrono
On 19/04/2017 08:29, Vlad Khorsun wrote:
> PS If i understand Sean correctly, he going to read data by few connectins in
> parallel.
> I think, it could work. Also, i guess, it shoudl be possible to use same
> "array DML +
> asynchronous queries" from parallel connections too
>
>
Would make thing
19.04.2017 13:29, Vlad Khorsun wrote:
>I can't evaluate something not defined. Specify "array DML + asynchronous
> queries" and,
> probably, we will have the subject to speak about.
Array DML is a way to put/get many records using one API call. In ODBC it is
https://docs.microsoft.com/en-
On 19/04/2017 08:56, Dimitry Sibiryakov wrote:
> Currently no SQL server allow to send two queries in single connection
> in parallel, so Firebird can be the first.
There must be a good reason for this, it's not only about hard
implementation.
You'd then need to offer concurrency control for the
19.04.2017 14:56, Dimitry Sibiryakov wrote:
> 19.04.2017 13:29, Vlad Khorsun wrote:
>> I can't evaluate something not defined. Specify "array DML +
>> asynchronous queries" and,
>> probably, we will have the subject to speak about.
>
> Array DML is a way to put/get many records using one
19.04.2017 14:07, Adriano dos Santos Fernandes wrote:
> Transaction consistency and multiple connections are a sufficient and
> easier to use feature.
CORE-5483 is also sufficient and easy to use, but still you called it "a
hack" with rage.
--
WBR, SD.
--
19.04.2017 14:12, Vlad Khorsun wrote:
>It give nothig to readers
Not quite so. When array binding used with select, client can send request
for new
packet before it start tossing record values into user buffers and this way
work in
parallel with server and network, reducing total wait t
19.04.2017 16:35, Dimitry Sibiryakov wrote:
> 19.04.2017 14:12, Vlad Khorsun wrote:
>> It give nothig to readers
>
> Not quite so. When array binding used with select, client can send
> request for new
> packet before it start tossing record values into user buffers and this way
> work i
19.04.2017 15:56, Vlad Khorsun wrote:
>And it does it already for a many years when fetching records in a batch
> (default mode)
Really? I see in sources that it send op_fetch only when in REM_fetch() it
run out of
data in buffer, not right after receiving batch.
>We speak about par
> 19.04.2017 14:07, Adriano dos Santos Fernandes wrote:
> > Transaction consistency and multiple connections are a sufficient and
> > easier to use feature.
>
>CORE-5483 is also sufficient and easy to use, but still you called it "a
> hack"
> with rage.
Because it is a "hack".
You (solely
19.04.2017 16:51, Leyne, Sean wrote:
> The functionality being discussed in this thread; cannot be overcome by a
> developer
It can. Nothing prevent you from starting several read-only snapshot
transactions at
once. If they all are started without any commit between them (which can be
ensur
>It can. Nothing prevent you from starting several read-only snapshot
> transactions at once. If they all are started without any commit between
> them (which can be ensured by a number of different ways)
Really, how?
I have client with over 500 connection to a database, I am pretty sure th
> 2- that the cost of any approach to ensure such "alignment" will not be so
> significant that it compromises system performance.
Ooppps!
That should have read:
2- that the cost of any approach to ensure such "alignment" *will be* so
significant that it compromises system performance.
Sean
> once. If they all are started without any commit between them (which can
> be ensured by a
> number of different ways), they will give you completely the same view of
> data.
I'm listening. That would make my life lot easier in certain scenarios,
--
Mgr. Jiří Činčura
https://www.tabsoverspace
19.04.2017 18:54, Leyne, Sean wrote:
> I have client with over 500 connection to a database, I am pretty sure that:
>
> 1- there is no way to ensure that all the read-only processes can start a
> transaction without the possibility that another read/write transaction
> started in between them, o
19.04.2017 19:01, Leyne, Sean wrote:
> If the solution was simple, we wouldn't be having this discussion right now.
BTW, did you considered moving of these tables into separate database that
it can be
transferred between servers as whole using nbackup?
--
WBR, SD.
--
19.04.2017 18:54, Leyne, Sean wrote:
> I have client with over 500 connection to a database, I am pretty sure that:
>
> 1- there is no way to ensure that all the read-only processes can start a
> transaction without the possibility that another read/write transaction
> started in between them, o
> > 2- that the cost of any approach to ensure such "alignment" will not be so
> significant that it compromises system performance.
>
>The simplest method: ON COMMIT trigger waiting for some flag to be
> unset. You set flag, start your transactions and then reset the flag.
> Performance pen
19.04.2017 17:12, Dimitry Sibiryakov wrote:
> 19.04.2017 15:56, Vlad Khorsun wrote:
>> And it does it already for a many years when fetching records in a batch
>> (default mode)
>
> Really? I see in sources that it send op_fetch only when in REM_fetch()
> it run out of
> data in buffer,
19.04.2017 20:43, Jiří Činčura wrote:
>> once. If they all are started without any commit between them (which can
>> be ensured by a
>> number of different ways), they will give you completely the same view of
>> data.
>
> I'm listening. That would make my life lot easier in certain scenarios,
19.04.2017 22:10, Leyne, Sean wrote:
> Again, you are thinking far too narrowly -- trying to define a problem to
> convenience frame of reference.
Ok, let me think wider: tell me why you need to move whole tables to other
server so
often and so quickly? May be you'd better use continuous rep
> > Really, how do you propose to coordinate the transactions account the
> separate processes (potentially different hosts)?
>
>What? So far you talked about transactions from one multi-threaded
> application. Where "different hosts" came from all of sudden?
I never said anything about a s
>Could you explain, please ?
Sure. There's a part of our system that reads data and sends these over
the internet. Given the deployments on the customer side the internet is
often very very slow (<100kBps sometimes), so we decided to not keep
transaction open, but do it repeatedly in bacches (
38 matches
Mail list logo