[firebird-support] Dialect 1 vs. 3: DATE to VARCHAR CAST results in different date/time format

[Thomas Steinmaurer t...@iblogmanager.com [firebird-support]]

Hello,

Executing the following in both, dialect 1 and 3:

select cast(current_timestamp as varchar(30))from rdb$database


results in a string with a different date/time format. At least on 
Windows with Firebird 2.5 64-bit.

Dialect 1: 7-DEC-2015 20:29:12.3820
Dialect 3: 2015-12-07 20:31:07.2280

Is this intended?

Thanks.


-- 
With regards,
Thomas Steinmaurer
http://www.upscene.com/

Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.

Re: [firebird-support] Dialect 1 vs. 3: DATE to VARCHAR CAST results in different date/time format

[Thomas Steinmaurer t...@iblogmanager.com [firebird-support]]

> On 8-12-2015 09:52, Thomas Steinmaurer t...@iblogmanager.com
> [firebird-support] wrote:
>> Hello,
>>
>> Executing the following in both, dialect 1 and 3:
>>
>> select cast(current_timestamp as varchar(30))from rdb$database
>>
>>
>> results in a string with a different date/time format. At least on
>> Windows with Firebird 2.5 64-bit.
>>
>> Dialect 1: 7-DEC-2015 20:29:12.3820
>> Dialect 3: 2015-12-07 20:31:07.2280
>>
>> Is this intended?
>
> It is intended, the dialect 3 format conforms to the SQL standard to
> always use ISO-8601 format, while dialect 1 preserves backwards
> compatibility by using a locale specific conversion.
>
> See also http://ibphoenix.com/resources/documents/design/doc_169

Thanks Mark.


-- 
With regards,
Thomas Steinmaurer
http://www.upscene.com/

Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.

Re: [firebird-support] FB lock files

[Hugo Eyng hugoe...@msn.com [firebird-support]]

Hi Rudi.

Look at this 
http://www.janus-software.com/fbmanual/manual.php?book=admin=23


Consider to change DefaultDbCachePages in firebird.conf.  You should 
read about this, because it depends if you use super server, classic or 
super classic.


DatabaseGrowthIncrement  is a  parameter that can affect the database 
performance too.


Hugo  Eyng


Em 07/12/2015 16:52, Rudi Feijó rudi.fe...@multidadosti.com.br 
[firebird-support] escreveu:


I noticed our biggest data server have a lot of hard disk activity 
creating fb_lock files.


Firebird 2.5.4, superclassic

My changed lock configurations are :

#LockMemSize = 1048576

LockMemSize = 10097152

#LockHashSlots = 1009

LockHashSlots = 60589

Should I try to set them higher? If so, whats a good parameter to know 
by how much I should increase it?





--


Atenciosamente,

Hugo Eyng

Re: [firebird-support] FB lock files

[Alexey Kovyazin a...@ib-aid.com [firebird-support]]

Hi Rudi,

You did not provide all required information to give you a reasonable 
answer.
At least, post fb_lock_print -d  output.


Regards,
Alexey Kovyazin
Try HQbird now! www.hqbird.com






++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu.  Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ 

++


Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[firebird-support] UTF8 charset with case insensitive match

[r...@seedsbydesign.com [firebird-support]]

I've used FB for years with ISO8859_1 charset and collation.
 

 Now I designing a new DB for a big app update in FB3 and wonder about this 
charset and collation.
 

 For test purposes I am using UTF8 and UNICODE_AI_CI and I like that I can now 
don't have to worry about casing comparisons nor accents or other special 
characters.
 

 In fact though, all the data in will be in the regular english-us alphabet 
with maybe a little in spanish for things like "japapeño", but still all single 
byte chars.
 

 From what I read, only one byte is used for storing these characters, so the 
same amount of space would be used as compared to ISO8859_1.
 

 What I am wondering before I get too far along, is there any downside to using 
UTF8 and UNICODE_AI_CI?
 

 Regards,
 Rick
  

[firebird-support] Charset UTF8 or ISO8859_1 for new DB with CI + AI

[r...@seedsbydesign.com [firebird-support]]

I've used FB for years with ISO8859_1 charset and collation.
 

 Now I designing a new DB for a big app update in FB3 and wonder about this 
charset and collation. My goal is to avoid having to UPPER everything for 
comparison searches.
 

 For test purposes I am using UTF8 and UNICODE_AI_CI and I like that I can now 
don't have to worry about casing comparisons nor accents or other special 
characters.
 

 In fact, all the stored data in will be in the regular english-us alphabet 
with maybe a little in spanish for things like "japapeño", but still all single 
byte chars.
 

 Here are my questions:
 

 1. Is only one byte used for storage for english and spanish?
 2. Is there any CI + AI collation for ISO8859_1?
 3. Is there any downside to using UTF8 and UNICODE_AI_CI over ISO8859_1 and 
collation ISO8859_1?
 

 Regards,
 Rick
 

Re: [firebird-support] UTF8 charset with case insensitive match

[Richard Damon rich...@damon-family.org [firebird-support]]

On 12/8/15 2:26 PM, r...@seedsbydesign.com [firebird-support] wrote:
>
> I've used FB for years with ISO8859_1 charset and collation.
>
> Now I designing a new DB for a big app update in FB3 and wonder about 
> this charset and collation.
>
> For test purposes I am using UTF8 and UNICODE_AI_CI and I like that I 
> can now don't have to worry about casing comparisons nor accents or 
> other special characters.
>
> In fact though, all the data in will be in the regular english-us 
> alphabet with maybe a little in spanish for things like "japapeño", 
> but still all single byte chars.
>
> From what I read, only one byte is used for storing these characters, 
> so the same amount of space would be used as compared to ISO8859_1.
>
> What I am wondering before I get too far along, is there any downside 
> to using UTF8 and UNICODE_AI_CI?
>
> Regards,
>
> Rick
>
UTF-8 uses 1 byte for code points 0-127 (the basic ASCII Characters), 
and two or more bytes  for other characters (like ñ), so you may take a 
small hit is data size. Code pages like ISO8859-1 represent all 
characters in a single byte (for those they represent).


-- 
Richard Damon

Re: [firebird-support] Charset UTF8 or ISO8859_1 for new DB with CI + AI

[Hannes Streicher hstreic...@gmx.de [firebird-support]]

Guten Tag r...@seedsbydesign.com [firebird-support],

> Here are my questions:


> 1. Is only one byte used for storage for english and spanish?
NO  plain englisch will still be one Byte but spanisch (the accented n ) will 
be multiple bytes


> 3. Is there any downside to using UTF8 and UNICODE_AI_CI over ISO8859_1 and 
> collation ISO8859_1?
UTF8 will always reserve 4 bytes per "Char" in Transferbuffers  because a UTF8 
Char can be up to 4 Bytes long

if have not looked at FB 3 but in 2.5 the maximum size of a varchar is some 
32000 Char  , due to the 4 Byte/Char
space reservation mechanism this will go down to 8000 and some for UTF8 Encoded




> Regards,

> Rick



>   
>
>  
> 


-- 
Mit freundlichen Grüssen
Hannes Streichermailto:hstreic...@gmx.de

RE: [firebird-support] string difficulty

['Andrew Zenz' and...@aimsoftware.com.au [firebird-support]]

My bad, should read more carefully.

 

Andrew Zenz

 

 



From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] 
Sent: Tuesday, 8 December 2015 6:12 PM
To: firebird-support@yahoogroups.com
Subject: AW: [firebird-support] string difficulty

 

  

Hello,

 

but this ist almost realized in my code, isn't it?

 

>From right until there is no * present

 

 

Von: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] 
Gesendet: Montag, 7. Dezember 2015 23:28
An: firebird-support@yahoogroups.com
Betreff: RE: [firebird-support] string difficulty

 

  

How about working backwards through the string?

 

Andrew Zenz

 



From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] 
Sent: Tuesday, 8 December 2015 6:59 AM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] string difficulty

 

  

Den 07.12.2015 13:55, skrev 'checkmail' check_m...@satron.de
  
[firebird-support]:
> .. and if the ID has the length of 15 chars and only the las * is for 
filling out to 16, i get a wrong result too.
>
> Can I compact my code?
>
> if(char_length(str)>16) then
> begin
> str = left(:str,16);
> while (k = 1) do
> begin
> if(right(str, 1) = '*') then
> begin
> str = left(str,char_length(str)-1);
> end
> else
> begin
> teil = str;
> k = 0;
> end
> end
> end
>
> (exept the one begin-end (only one command can be without..)
>

http://www.firebirdsql.org/refdocs/langrefupd25-intfunc-trim.html
 

Hence, I think your 16 lines above can be replaced by one simple line 
(if you use Fb 2.5):

str = trim (trailing '*' from left(:str, 16));

HTH,
Set