Issue Details (XML | Word | Printable)

Key: CORE-4181
Type: Improvement Improvement
Status: Open Open
Priority: Minor Minor
Assignee: Unassigned
Reporter: Simonov Denis
Votes: 0
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Update tool to use new API functionality

Created: 14/Aug/13 06:37 AM   Updated: 17/Dec/16 04:48 PM
Component/s: ISQL
Affects Version/s: 3.0 Alpha 1
Fix Version/s: None

Issue Links:
Relate
 

Sub-Tasks  All   Open   

 Description  « Hide
The current version of isql uses the old API. As a result, we have a limit on the width of the sample in the 64K, and the length of the query. A simple example demonstrates this:

select lpad('', 30000, '1') as f1,
       lpad('', 30000, '1') as f2,
       lpad('', 15000, '1') as f3
from rdb$database

Statement failed, SQLSTATE = 07002
SQL error code = -804
-SQLDA missing or incorrect version, or incorrect number/type of variables
SQL>

In Firebird appeared packages, their body can be quite long. And it turns out that to run the script through isql to create the package will not work longer than 64K. Dmitry Yemanov also spoke about the fact that it is desirable that isql able to dynamically load a library fbclient in order to be able to work with the old version.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Adriano dos Santos Fernandes added a comment - 20/Aug/13 04:17 PM
New API does not increase the maximum size of messages.

Amd FWIW, I'm running very large execute block, after increased the size of ISQL buffer.

Please test the current snapshot.

Simonov Denis added a comment - 20/Aug/13 04:56 PM
I checked isql on the large block.

1. Short block

set term ^;
execute block
returns (s integer)
as
begin
  s = 5;
  suspend;
end^
set term ;^

           S
============
           5


2. Long block (~ 5 Mb)

set term ^;
execute block
returns (s integer)
as
begin
 /***************************************************************************/
 /***************************************************************************/
 /***************************************************************************/
.................................................................
 /***************************************************************************/
  s = 5;
  suspend;
end^
set term ;^

           S
============
           5

It seems works. But there is a lot of comment and few commands. It is advisable to check certainly something more real.

Sean Leyne added a comment - 20/Aug/13 04:58 PM - edited
Adriano,

Unfortunately, the v3 Alpha release notes suggests otherwise.

Page 74 reads:

- The total size of all input or output parameters for a stored procedure or a user-defined DSQL query is no
longer limited to the traditional size of (64KB - overhead).

Adriano dos Santos Fernandes added a comment - 20/Aug/13 05:15 PM
This seems to be a documentation error.

Dmitry Yemanov added a comment - 20/Aug/13 05:23 PM
As the one who's responsible I respectfully disagree :-) First of all, there's no 64KB limit for the message length priorly defined by MAX_FORMAT_SIZE (see GEN_port for example). Now it's limited by MAX_MESSAGE_SIZE which is defined as 10MB. Secondly, new API offers 32-bit lengths for everything while the legacy one used 16-bit lengths for everything.

Simonov Denis added a comment - 20/Aug/13 05:26 PM
Adriano,

Then why CORE-1609 fixed?

Sean Leyne added a comment - 20/Aug/13 05:30 PM
@Dmitry, so this is a real case/issue?

Dmitry Yemanov added a comment - 20/Aug/13 05:32 PM
Denis, I'm afraid CORE-1609 is fixed only partially and may require reopening. There's no API level (message related) limit for procedures anymore, but there's still a 64KB record limit which applies to the current row of selectable procedures. In other words, you can execute a procedure returning >64KB in one row, but you cannot select from it. I'll look whether it's easily doable without increasing the table records length (which is a major ODS change).

Dmitry Yemanov added a comment - 20/Aug/13 05:37 PM
@Sean, this ticket is valid. ISQL can execute longish queries just because it passes strings zero-terminated and does not pass their length (which is 16-bit in the old API). It gonna work with the new fbclient only, because older ones will truncate the string while passing it through the wire. But other extended limits (like the aforementioned input/output message size) require usage of the new API, ISQL cannot deal with such queries.

Adriano dos Santos Fernandes added a comment - 20/Aug/13 05:37 PM
Dmitry, I was not aware! But good then!

Then, if new limits can exists only in the old API, what prevent us from define metadata with real UTF-8 and have names with lengths greater than 31 *bytes* ?

The problem, as I known, was only to represent the names in the DSQL API.

Sean Leyne added a comment - 20/Aug/13 05:46 PM
@Dmitry, but if we are releasing a new build and ISQL uses FBClient, it would seem reasonable that the v3 ISQL tool should support all of the v3 functionality (to the full extent of the v3 Client API).

The fact that older clients (fbclient.dll) would not support the new functionality in understood.

Dmitry Yemanov added a comment - 20/Aug/13 05:48 PM
Adriano, in turn I may be ignorant about the metadata names vs DSQL API issue :-) If you mean limits inside XSQLVARs, then how longer metadata names could be accessed using the old API? Anyway, I suggest to move this discussion to fb-devel.

Sean Leyne added a comment - 20/Aug/13 05:50 PM
@Adriano, support for longer object names is a separate feature request, so let's not "pollute" this case with discussion on that subject.

That change, though, which would require a major ODS change (which it seems is being avoided in v3)

Rashid Abzalov added a comment - 16/Dec/16 12:04 PM
@Dmitry Yemanov

>>but there's still a 64KB record limit which applies to the current row of selectable procedures. In other words, you can execute a procedure returning >64KB in one row, but you cannot select from it.

Does this limit also applies to record size of result set from simple select query?
Does this limit exists in current release (3.0.1)?

According to the documentation (http://firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-psql-limitsoff.html) this limits have been raised.
Or I have misunderstood?

Dmitry Yemanov added a comment - 17/Dec/16 04:48 PM
These limits are not actual in v3 anymore.