Thu, 5 Jul 2012 12:57:02 + (GMT+00:00) от "JLM (JIRA)"
:
FIrebird for Android
Key: CORE-3885
URL: http://tracker.firebirdsql.org/browse/CORE-3885
Project: Firebird Core
Issue Type: Task
Components: Buil
>>> Why not make the DEFAULT CHARACTER SET clause required? So everybody
>>> who creates a database *must* define one and make sure it's the right
>>> one.
>> Yes, this is also an option. Maybe even the easiest one.
> Sure, although it's going to break an unknown number of user scripts.
> From a
>
>
>
> Interesting. Could you show also miliseconds part of the timestamp ?
> It is very possible, that tx 948265
> was really created few ms before tx 938474 but obtains its number after it
> (due to threads preempting by OS
> scheduler and needs to obtain EX lock for header page to assign tx
> Hello, y write to the developer group because i'm observing a very strange
> behaviour in transaction counter,
> and i don't know what needed for open it in the tracker.
>
> I use 2.5.2 superclassic in windows 2008 server 64 bits. I have migrated one
> customer from Interbase 2009
> to Fireb
Sorry one mistake, in the phrase
I use 2.5.2 superclassic in windows 2008 server 64 bits. I have migrated
one customer from Interbase 2009 to Firebird two years ago, is two days
ago, not two years.
2012/7/6 Jesus Garcia
> Hello, y write to the developer group because i'm observing a very strange
Hello, y write to the developer group because i'm observing a very strange
behaviour in transaction counter, and i don't know what needed for open it
in the tracker.
I use 2.5.2 superclassic in windows 2008 server 64 bits. I have migrated
one customer from Interbase 2009 to Firebird two years ago.
06.07.2012 10:33, Dmitry Yemanov wrote:
> So you mean that the database is created before it becomes known what is
> the application charset, right?
Not quite so. Actually, I don't care about data character set at all. That's
the case
where charset NONE fits perfectly.
--
WBR, SD.
---
06.07.2012 12:20, Dimitry Sibiryakov wrote:
> I have a script which creates my tables in my own just created database or
> any existing
> user-choosen database. Because I can't predict default character set of such
> user
> database, all fields in this script are created with explicit character
On Fri, 06 Jul 2012 10:20:13 +0200, Dimitry Sibiryakov
wrote:
>I have a script which creates my tables in my own just created
database
>or any existing
> user-choosen database. Because I can't predict default character set of
> such user
> database, all fields in this script are created w
06.07.2012 10:10, Dmitry Yemanov wrote:
> As usual, by connecting to the service manager and asking for the server
> version.
It would require from me to parse user-entered connection string to extract
server
name. And then - parsing string returned from service manager to extract the
versio
06.07.2012 9:54, Mark Rotteveel wrote:
>> >Shouldn't it be coupled with prohibiting declaration of charset for
>> >single fields?
>> >Currently nothing prevent (me) from creating database with default
> charset
>> >NONE and set
>> >charset for every character field in every table.
> I am no
06.07.2012 11:54, Mark Rotteveel wrote:
> I am not sure I see why you would need to prohibit setting the
> characterset of a specific field when requiring the default characterset to
> be set. Could you explain the reasoning on that?
I believe his was referring to the default charset being set to
06.07.2012 11:45, Dimitry Sibiryakov wrote:
> How about isc_create_database()? Should it follow the same rules?
Sure.
> Shouldn't it be coupled with prohibiting declaration of charset for single
> fields?
> Currently nothing prevent (me) from creating database with default charset
> NONE and s
On Fri, 06 Jul 2012 09:45:06 +0200, Dimitry Sibiryakov
wrote:
>How about isc_create_database()? Should it follow the same rules?
It probably should.
>> But if we'd go this route, one more idea comes to mind. What about
>> prohibiting NONE as a default database charset at all, even if
specifi
On Fri, Jul 6, 2012 at 10:01 AM, Mark Rotteveel wrote:
> On Fri, 6 Jul 2012 09:22:13 +0300, marius adrian popa
> wrote:
> > I propose that default dialect to be Dialect 3 and dropping support for
> > dialect 1 in far and future Firebird 3.5.x/4.x for example (mark is as
> > deprecated and it will
06.07.2012 6:57, Dmitry Yemanov wrote:
> 06.07.2012 8:37, Roman Rokytskyy wrote:
>>
>>> Why not make the DEFAULT CHARACTER SET clause required? So everybody
>>> who creates a database *must* define one and make sure it's the right
>>> one.
>>
>> Yes, this is also an option. Maybe even the easiest o
On Fri, 6 Jul 2012 09:22:13 +0300, marius adrian popa
wrote:
> I propose that default dialect to be Dialect 3 and dropping support for
> dialect 1 in far and future Firebird 3.5.x/4.x for example (mark is as
> deprecated and it will not do anything when set)
>
> in python driver and perl driver d
17 matches
Mail list logo
