[firebird-support] Hello, from new member

2020-02-26 Thread 'm...@spectrumpacsold.com' m...@spectrumpacs.com [firebird-support]
Hello Group,

 �

  Thanks for letting me join.  I have one customer for my income and am 
semi-retired.  I am a long time user / sys admin of Firebird 2.7.1 and I need 
to migrate this version from a Windows Server 2003 OS to a newer Windows Server 
2016. It is on a VMware server and has been for many years. Admins say 2003 is 
not being supported soon, same MS generated obsolete and no support message but 
the domain admins want to upgrade it.I know there are always issues but for 
base compatibility,  will this new OS work?  Any information on compatibility 
between Firebird versions and Windows server OS would be most welcome.

 �

Regards,

 �

~Mike



Re: [firebird-support] double precision remove last 2 numbers

2020-02-26 Thread hamacker sirhamac...@gmail.com [firebird-support]
  Maybe between 8 and 15 decimals, not more.

Em qua., 26 de fev. de 2020 às 16:10, Dimitry Sibiryakov s...@ibphoenix.com
[firebird-support]  escreveu:

> 26.02.2020 19:41, hamacker sirhamac...@gmail.com [firebird-support] wrote:
> > I need to store long decimals numbers maybe more than 15 decimals, is it
> possible without
> > store as string?
>
>If your task requires such number you should consider using of Firebird
> 4 or Oracle.
>
>
> --
>WBR, SD.
>
>
> 
>
> 
>
> ++
>
> 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
>
>
>
>


Re: [firebird-support] double precision remove last 2 numbers

2020-02-26 Thread Dimitry Sibiryakov s...@ibphoenix.com [firebird-support]
26.02.2020 19:41, hamacker sirhamac...@gmail.com [firebird-support] wrote:
> I need to store long decimals numbers maybe more than 15 decimals, is it 
> possible without 
> store as string?

   If your task requires such number you should consider using of Firebird 4 or 
Oracle.


-- 
   WBR, SD.






++

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/



Re: [firebird-support] double precision remove last 2 numbers

2020-02-26 Thread hamacker sirhamac...@gmail.com [firebird-support]
When I started my test, I turn off my app.
And do update(and select) using only ISQL tool (IBExpert) and dbweaver.
in both I had to configure select to show float using mask (0.##..), so
the number can be different that I show you, but always eat last numbers.
I need to store long decimals numbers maybe more than 15 decimals, is it
possible without store as string?

Em qua., 26 de fev. de 2020 às 15:21, Mark Rotteveel m...@lawinegevaar..nl
[firebird-support]  escreveu:

>
>
> On 2020-02-26 19:07, hamacker sirhamac...@gmail.com [firebird-support]
> wrote:
> > Hi All,
> >
> > I do this update:
> > UPDATE CV SET
> > perc_lucro=42.503064336972848
> > WHERE (id_cv=57528)
> >
> > Then I do a select and 'perc_lucro' was change to 42,5030643369728
> > after updated, two last numbers disappear.
> > Why?
> > perc_lucro is double precision type.
> > FB 3.0.5 32bits, Windows 64.
>
> A double precision is not an exact numeric type, it has roughly a
> precision of 15-17 decimals. Even that isn't entirely correct because of
> how a double precision works. In any case, a double precision cannot
> exactly store 42.503064336972848.
>
> However, when testing this (with `select cast(42.503064336972848 as
> double precision) from rdb$database`), I get a value of
> 42.50306433697285, which suggest that your software may do some
> additional rounding or truncation when presenting the value.
>
> Mark
> 
>


Re: [firebird-support] double precision remove last 2 numbers

2020-02-26 Thread Mark Rotteveel m...@lawinegevaar.nl [firebird-support]
On 2020-02-26 19:07, hamacker sirhamac...@gmail.com [firebird-support] 
wrote:
> Hi All,
> 
> I do this update:
> UPDATE CV SET
>   perc_lucro=42.503064336972848
> WHERE (id_cv=57528)
> 
> Then  I do a select and 'perc_lucro' was change to 42,5030643369728
> after updated, two last numbers disappear.
> Why?
> perc_lucro is double precision type.
> FB 3.0.5 32bits, Windows 64.

A double precision is not an exact numeric type, it has roughly a 
precision of 15-17 decimals. Even that isn't entirely correct because of 
how a double precision works. In any case, a double precision cannot 
exactly store 42.503064336972848.

However, when testing this (with `select cast(42.503064336972848 as 
double precision) from rdb$database`), I get a value of 
42.50306433697285, which suggest that your software may do some 
additional rounding or truncation when presenting the value.

Mark


[firebird-support] double precision remove last 2 numbers

2020-02-26 Thread hamacker sirhamac...@gmail.com [firebird-support]
Hi All,

I do this update:
UPDATE CV SET
  perc_lucro=42.503064336972848
WHERE (id_cv=57528)

Then  I do a select and 'perc_lucro' was change to 42,5030643369728 after
updated, two last numbers disappear.
Why?
perc_lucro is double precision type.
FB 3.0.5 32bits, Windows 64.


Re: [firebird-support] (When to) recalculate statistics ?

2020-02-26 Thread Mark Rotteveel m...@lawinegevaar.nl [firebird-support]
On 2020-02-26 06:22, Matthias Winkler spmm...@gmail.com 
[firebird-support] wrote:
> Hello Firebird-Group,
> 
> With our device we recalculate statistics ALWAYS when booting up the
> system. Now the DB grows bigger this can now take more than 10 minutes
> and delays
> the time until we can really work with the system. As it is not a
> server and we expect the system to be restart from time to time this
> is a problem.

Recalculating statistics is not a blocking operation. If done correctly 
(eg in a separate thread or process), your system should be available 
immediately, with a (minor) impact on performance.

> Is there a better way to find out when to recalculate statistics?
> - After n inserts?
> - After n days?
> 
> And: Is it really such a big performance benefit to recalc the
> statistics at all?

The statistics in Firebird are pretty basic, and recalculating them 
daily will not add much value. The resulting statistics will likely be 
very similar to the previous and not change the optimizers decisions. 
After a database has been filled with a representative set of data, 
recalculating statistics might be of value after an order of magnitude 
change in volume (number of records), or if the selectivity of an index 
changes significantly (eg if previously an indexed column had only a few 
different values (low selectivity), and now has a lot of different 
values (high selectivity)), and even that might be debatable.

Mark


RE: [firebird-support] (When to) recalculate statistics ?

2020-02-26 Thread liviuslivius liviusliv...@poczta.onet.pl [firebird-support]
HiTo take decision you first must know what statistics are for server e.g. 
Firebird. Statistics contain info how selective is some index. If it is PK you 
know that every entry have only one record. For UK you have same but you can 
have multiple nulls. For other indexes you can have for one entry multiple 
references to records. Simple sample index of people name. You can have 
multiple people with same name.Index selectivity is used when Firebird 
optimizer choose plan for the query. Without information about selectivity or 
with not recent information it can decide wrongly and generate "wrong" query 
plan. And query can then run slow. If your queries have good plan and run fast 
then you can e.g stop recalculating statistics at all.As you can see it 
depend..You must decide how offten. Regards,Karol Bieniaszewski
null