Adriano dos Santos Fernandes wrote:
> On 03/06/2016 10:35, Geoff Worboys wrote:
>> This is not a request, I am just asking whether the option
>> has been considered as a way of maintaining backward
>> compatibility.
> Not considered nor will.
> No reason to introduce such things for so small and e
>> I'd prefer to introduce XSQLDA version 2.
>Then it should also include schema name (reserved now), to avoid yet
another version switch in the future.
And package name ...
Dmitry Kovalenko
www.ibprovider.com
--
03.06.2016 16:22, Dmitry Yemanov wrote:
> Then it should also include schema name (reserved now), to avoid yet
> another version switch in the future.
Sure. May be even open-ended set of XSQLVAR properties is possible if
designed
carefully. But there is no rush to design it right now.
--
On 03/06/2016 10:35, Geoff Worboys wrote:
> This is not a request, I am just asking whether the option has
> been considered as a way of maintaining backward compatibility.
Not considered nor will.
No reason to introduce such things for so small and easy to fix problem
with is not even a problem i
Adriano dos Santos Fernandes wrote:
...
> Older than v4 tools (isql, gbak) connecting to v4 server
> should not work correctly only when dealing with longer
> than 31 characters names.
...
Have you considered (and perhaps rejected) supporting both old
and new through the use of some sort of short-
Problem of lower() and upper() commands
-
Key: CORE-5259
URL: http://tracker.firebirdsql.org/browse/CORE-5259
Project: Firebird Core
Issue Type: Bug
Affects Versions: 2.5.5
Environment:
03.06.2016 16:30, Dimitry Sibiryakov wrote:
>> I treat this problem as low priority, but supposing we're going to do
>> something to users of the legacy API access longer names, I think the
>> best method is to have a function that obtains an IStatement from an
>> isc_stmt_handle and read them wit
Hi Adriano,
I was thinking about this - the issues are more complex when you take into
consideration the ideas of schema.
I was looking at the issue and was trying to consider the best path forward.
The options I saw where as follows
1. Extend the name, let the user correct the ddl before u
03.06.2016 15:11, Adriano dos Santos Fernandes wrote:
> The major thing to discuss here is, what should be that character limit:
> 64, 128, other?
From MSDN: "SQL_MAX_IDENTIFIER_LEN(ODBC 3.0)
An SQLUSMALLINT that indicates the maximum size in characters that the
data source
supports for
Hi!
I started patch for longer metadata names and at the same time changing
UNICODE_FSS to UTF8 in system tables and also changing the byte-limit to
character-limit in them.
The major thing to discuss here is, what should be that character limit:
64, 128, other?
Older than v4 tools (isql, gbak)
03.06.2016 10:09, liviuslivius wrote:
>
> PS. why this is not compatibile? I can think about procedures and triggers
> but alredy existing triggers and procedures have not more then 256 contexts.
> This can not be changed as version number in blr?
New BLR version (e.g. introduced in v3.0.1) will
Hi,
sadly to hear about v3.
But good to see that this is in progress :)
Thanks for the info.
PS. why this is not compatibile? I can think about procedures and triggers but
alredy existing triggers and procedures have not more then 256 contexts.
This can not be changed as version number in blr?
12 matches
Mail list logo
