Re: [firebird-support] Generators, what could cause resetting generator values to some earlier version

[Ann Harrison]

On Fri, Aug 10, 2012 at 3:59 PM, Lester Caine  wrote:

> Again Windows seems to be a little too cleaver at times. While it may have
> reported a failed write, it still works as if the cached data has been
> written?
> Even with Forced Writes on :(
>
>
The problem may not be Windows, but the cache in the disk controller.
 Disks are much faster if they say the data is on disk when it's just in
the cache.  Possibly the generator page is so hot it never gets to disk?

Good luck,

Ann


[Non-text portions of this message have been removed]

RE: [firebird-support] Transactions & exception trapping

[Helen Borrie]

At 05:00 AM 11/08/2012, Rick Debay wrote:
>FOR ... BEGIN
>  INSERT_PROCEDURE RETURNING VALUE
>  UPDATE TABLE WITH VALUE
>  WHEN ... BEGIN
>LOG
>  END
>END
>
>If the insert procedure directly or indirectly causes an exception the
>insert will be abandoned, the update will be skipped, and all data from
>previous or subsequent non-erroneous loop iterations will be preserved.
>
>Now if the update fails, would the inserted data within the same loop
>iteration be preserved?  I've been assuming that everything within the
>BEGIN...END was abandoned.

The handler is not embedded in the loop that it handles: it follows directly 
after. The flow should be:

FOR ... do
  BEGIN
INSERT_PROCEDURE RETURNING VALUE
UPDATE TABLE WITH VALUE
  end
WHEN ... do
  BEGIN
LOG
  END

If an exception occurs anywhere in an iteration of that loop, everything within 
that iteration is abandoned, control drops into the WHEN block and executes 
that before returning to the top of the loop.  

If a handler block is not found directly after the looping block, control moves 
out through the layers until one is found that fits the exception.   Everything 
enclosed by the block whose handler is found is abandoned.  

Ultimately, if no explicit handler is found in the enclosing layers that fits 
the exception, control drops to the EXIT statement and the entire work of the 
procedure is abandoned.

./heLen

[firebird-support] Re: Improving execution time

[joernheitland]

 wrote:
>
> >SELECT r.LINENR, r.COMPONENTNR, MAX(r.SUMWEIGHT)-MIN(r.SUMWEIGHT) as 
> >sumweightdiff 
> >FROM GRAVCOMPDATA_LONG r 
> >where r.GRAVTIMESTAMP Between  CAST('NOW' AS TIMESTAMP) - 60/1440e0 AND 
> >CAST('NOW' AS TIMESTAMP)
> >group by r.LINENR, r.COMPONENTNR
> 
> You forgot to mention the main part of any optimization task, the chosen 
> PLAN. This answer is therefore based on expecting indexes not to be optimized 
> for this query yet.
> 
> Is there any GRAVTIMESTAMP > 'NOW'? If not, then add a DESCENDING INDEX for 
> GRAVTIMESTAMP and change your query to:
> 
> SELECT r.LINENR, r.COMPONENTNR, MAX(r.SUMWEIGHT)-MIN(r.SUMWEIGHT) as 
> sumweightdiff 
> FROM GRAVCOMPDATA_LONG r 
> where r.GRAVTIMESTAMP >= CAST('NOW' AS TIMESTAMP) - 60/1440e0 
> group by r.LINENR, r.COMPONENTNR
> 
> Hopefully, this will change the PLAN and the execution time improve.
> 
> HTH,
> Set
>

Thanks a lot for this idea. I could reduce execution time tremendously:

Executing...
Done.
11189 fetches, 45 marks, 5624 reads, 30 writes.
0 inserts, 0 updates, 0 deletes, 1792 index, 0 seq.
Delta memory: 23356 bytes.
Total execution time: 0.296s
Script execution finished.

and yes there is no dedicated plan, and now I know I should give more attention 
to the chapter in hellens book ;-). Do you think that the additional index has 
an notable effect to the insertion time for the records ?.

Jörn

Re: [firebird-support] Generators, what could cause resetting generator values to some earlier version

[Lester Caine]

Helen Borrie wrote:
>> I had thought that caching of write data in windows had been sorted, but I'm 
>> not
>> >entirely surprised if just some block of data has been lost.
> I believe the OP mentioned that they were using Fb 2.1.3.  That's almost 
> three years old now and two sub-releases out of date.  I suspect the moves to 
> improve the caching behaviour on Windows came more recently.
Actually I was referring to Windows itself rather than Firebird, but the 
improvements in FB were done because of this sort of problem.

>> >If it was one of my sites I'd drop a new machine in just to prove a point 
>> >...
> The system log reports of disk corruption are suspicious...but they don't 
> account for lost generator values. If the generator page was actually written 
> to a corrupt block, I'd expect the page to be kaput and to see other evidence 
> of corruption.  It seems more likely the page write was lost when they had 
> that power failure.
> I wonder whether anyone has checked to see whether Forced Writes is off.  If 
> so, the chances of pending writes disappearing on a power outage would be 
> high.
Again Windows seems to be a little too cleaver at times. While it may have 
reported a failed write, it still works as if the cached data has been written?
Even with Forced Writes on :(

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Re: [firebird-support] Generators, what could cause resetting generator values to some earlier version

[Helen Borrie]

At 04:48 AM 11/08/2012, Lester Caine wrote:

>I had thought that caching of write data in windows had been sorted, but I'm 
>not 
>entirely surprised if just some block of data has been lost. 

I believe the OP mentioned that they were using Fb 2.1.3.  That's almost three 
years old now and two sub-releases out of date.  I suspect the moves to improve 
the caching behaviour on Windows came more recently. 

>If it was one of my sites I'd drop a new machine in just to prove a point ...

The system log reports of disk corruption are suspicious...but they don't 
account for lost generator values. If the generator page was actually written 
to a corrupt block, I'd expect the page to be kaput and to see other evidence 
of corruption.  It seems more likely the page write was lost when they had that 
power failure.

I wonder whether anyone has checked to see whether Forced Writes is off.  If 
so, the chances of pending writes disappearing on a power outage would be high.

./heLen

[firebird-support] Stored Procedure with one input parameter on DataSnap Server returning table

[Franz]

Please help with specifying components and parameters for the following 
situation:

1. DataSnap Server with one table TestParm and one stored proc TestSP:
begin
  TestOutput = :testInput*10;
  TestBlob = :TestInput * 100;
  insert into TestParm (TestInput, TestOutput, TestBlob) values (:TestInput, 
:TestOutput, :testblob);

  for
select TestInput, TestOutput, TestBlob
from TestParm
where TestParm.TestInput = :TestInput
into :TestCopyInput, :TestCopyOutput, :TestBlob
  do
begin
 suspend; 
end
end

2. Delphi XE2 DataSnap Server with a  unit ServerMethodsUnit.pas with
TSQLConnnection pointing at database with table TestParm
TDatasetProvider with property Dataset pointing at TSQLStoredProc
TSQLStoredProc with StoredProcName pointing at TestSP (see above)
Should my TestInput input parameter be filled in at Params?

3. On the Client side:
TSQLConnection with driver Datasnap
TSQLQuery with SQL string: 
select * from testsp  where TESTINPUT = :TESTINPUT;

Should any parameters be set in the Params property?

I tried all kinds of combinations, but get error messages all the time. I.e. 
dbx.sql is an unrecognized command type, invalid ordinal 0, parameter mismatch 
for procedure TestSP.

What should be the correct combination of components, parameters for this?

Please help!

Regards,

Franz

Re: [firebird-support] Re: Firebird hangs for a while blocking all DB operations periodically.

[Jesus Garcia]

Hello anthony, i have had the same issue in one of our clients. Because your 
problem, i thought that the problem was the same as yours. I have been 
monitoring firebird for three weeks, thinking  that the problem has the origin 
in firebird.

After sometime and headaches at last the problem was not firebird, was Norton 
antivirus installed in the server. When it updates virus definitions, the 
server is freezed for 5-10 minutes and after that all runs fine again until the 
next update cycle. 

The symptoms was the same as yours but firebird is not the only one running in 
the server.

Regards, jesus
> 


[Non-text portions of this message have been removed]

RE: [firebird-support] Transactions & exception trapping

[Rick Debay]

FOR ... BEGIN
  INSERT_PROCEDURE RETURNING VALUE
  UPDATE TABLE WITH VALUE
  WHEN ... BEGIN
LOG
  END
END

If the insert procedure directly or indirectly causes an exception the
insert will be abandoned, the update will be skipped, and all data from
previous or subsequent non-erroneous loop iterations will be preserved.

Now if the update fails, would the inserted data within the same loop
iteration be preserved?  I've been assuming that everything within the
BEGIN...END was abandoned.

-Original Message-
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Helen Borrie
Sent: Friday, August 10, 2012 12:35 AM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] Transactions & exception trapping

At 04:49 AM 10/08/2012, Rick Debay wrote:
>I have a table with before and after insert triggers.  I also have a 
>stored procedure that loops, inserting rows in to the table.  The last 
>statement in the loop is WHEN ANY to catch and log errors to an 
>external table and continue looping.
>
>If an insert trigger throws an exception, will the insert be rolled 
>back even though I'm catching the exception and continuing?  Or will 
>this subvert the triggers and allow inconsistent data?

Remember that an uncommitted transaction does not change database state.
Whatever is happening inside a transaction is known only to that
transaction.  

When an exception occurs, control will pass down to the first WHEN...
block it can find.  If that WHEN block is located directly at the end of
the block where the exception occurred, that block is executed (writes
out your log record) and, provided it has no direction to raise the
exception to an outer level, control passes back to the top of the same
loop. The abandoned operation, including anything it did or was expected
to do in triggers, is simply excluded from the list of stuff the
transaction has to do when it finally commits. ACID.

Previous or subsequent operations will not be affected by the
abandonment of the offending operation, unless something in the
procedure logic makes the iterations interdependent.  The database
engine cannot undo changes made to local objects, such as variables and
parameters so, when swallowing exceptions, there's more edge on the
imperative to be explicit and correct with the initialisation and timing
logic.

./hb








++

Visit http://www.firebirdsql.org and click the Resources item on the
main (top) menu.  Try Knowledgebase and FAQ links !

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

++
Yahoo! Groups Links

Re: [firebird-support] Generators, what could cause resetting generator values to some earlier version

[Lester Caine]

Sofija Blazevski wrote:
> That is very interesting to know about, thought I never had such case.
>
> Thank you for trying to help, it seems there are a lot of problems with
> either system or hardware, as one of our application files, out of
> nowhere came to filesize 0 and had to be replaced.

It sounds were much as if there is something causing a problem with the disk 
writes. I've seen the same problem in the past, but all of a days data missing 
- 
after printing the days reports. We found the culprit ... a cleaner just 
unplugging the computer to plug the vacuum cleaner in ,,, did not understand 
the 
'DO NOT SWITCH OFF' :(

I had thought that caching of write data in windows had been sorted, but I'm 
not 
entirely surprised if just some block of data has been lost. If it was one of 
my 
sites I'd drop a new machine in just to prove a point ...

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Re: [firebird-support] Generators, what could cause resetting generator values to some earlier version

[Ann Harrison]

On Fri, Aug 10, 2012 at 5:32 AM, Sofija Blazevski <
sofija.blazev...@grappologroup.com> wrote:

>
> This affected entire database (all generators actively in use), mostly
> generators are used for Integer columns, some are used for varchar
> columns in case like document number that has string prefix, the prefix
> can vary within a table.
>
> I'm not sure how could type of column produce a problem like this?
>
>
Values for generators are stored densely on a page - depending on the page
size, somewhere between a lot and a whole lot fit on a page (4 bytes per
generator, 4-16K bytes per page, less page overhead).  Generator pages are
written out when a transaction that changed them commits, so they should be
written often. It's vaguely possible there's something going on with your
disk...

Good luck


[Non-text portions of this message have been removed]

[firebird-support] Re: Firebird hangs for a while blocking all DB operations periodically.

[anthonyjang2012]

Vlad,

We have emailed a link to download two mini-dumps. Unfortunately, we could not 
obtain a lock-print. This mini-dump is from the original site that reported the 
problem and so it is the same as the original issue. Please let us know if this 
helps to resolve the issue.

Regards,

Anthony

--- In firebird-support@yahoogroups.com, "hvlad"  wrote:
>
> --- In firebird-support@yahoogroups.com, "anthonyjang2012" wrote:
> >
> > Vlad,
> > 
> > We have emailed a link to download the mini-dump and lock-print. 
> 
>   Just answered to you privately.
> 
> > Please let us know if this is helps to resolve the issue 
> 
>   Sure.
> 
> Regards,
> Vlad
>

Re: [firebird-support] Moving primary key to another column

[Milan Babuskov]

Matthias Hanft wrote:
> let's say I have a table like this
> 
> NBR  INTEGER  PRIMARY KEY
> SOMEFIELD1 VARCHAR
> SOMEFIELD2 VARCHAR
> [...]
> 
> Now I don't want to be NBR the primary key any more (the numbers there
> have a special meaning where I need to have some "0" entries now); I'd
> like to insert another "ID" colum which should be the new primary key
> (and filling it automatically from 1 to N by a generator).
> 
> Is this possible within the "live" database/table, or do I have to create
> a new table with the colums needed, and do some "INSERT INTO NEWTABLE
> SELECT FROM OLDTABLE" and finally rename the new table to the old name?
> 
> The server is FB 2.0.3; I have IBExpert and FlameRobin available.

All explained here:

http://firebirdfaq.org/faq380

Regards,

-- 
Milan Babuskov

==
The easiest way to import XML, CSV
and textual files into Firebird:
http://www.guacosoft.com/xmlwizard
==





++

Visit http://www.firebirdsql.org and click the Resources item
on the main (top) menu.  Try Knowledgebase and FAQ links !

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

++
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:
http://docs.yahoo.com/info/terms/

Re: [firebird-support] Re: execute statement

[Milan Babuskov]

Alexandre Benson Smith wrote:
> To achieve what he wants he will need to write an app (or stored 
> procedure, or whatever) that loops trough the fields and generate the 
> trigger PSQL code like

No need to write anything. In FlameRobin, you can right-click the table, 
select "Generate code" and then "Create change trigger for table".

It will display a dialog to select the desired columns and it will 
generate to complete trigger code.

HTH

-- 
Milan Babuskov

==
The easiest way to import XML, CSV
and textual files into Firebird:
http://www.guacosoft.com/xmlwizard
==

Re: [firebird-support] Finding when a Database Object was created

[Thomas Steinmaurer]

> Is it possible to perform a query against the system tables that will tell
> me when (Date) a certain trigger or stored procedure was created?

No.

> Or is there another way to get that information?

Via the Trace API might be an option, but possible for that purpose 
overkill.

In Firebird 3, there will be DDL triggers, which makes such things much 
easier.


Regards,
Thomas


>
>
>
> Regards
> Marius J. Labuschagne
>
>
>
>
> 
>
> ++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu.  Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++
> Yahoo! Groups Links
>
>
>

[firebird-support] Finding when a Database Object was created

[Marius Labuschagne]

Hello,

Is it possible to perform a query against the system tables that will tell
me when (Date) a certain trigger or stored procedure was created?

Or is there another way to get that information?



Regards
Marius J. Labuschagne

[firebird-support] Re: Improving execution time

[Svein Erling Tysvær]

>>
>> >SELECT r.LINENR, r.COMPONENTNR, MAX(r.SUMWEIGHT)-MIN(r.SUMWEIGHT) as 
>> >sumweightdiff FROM GRAVCOMPDATA_LONG r where r.GRAVTIMESTAMP Between  
>> >CAST('NOW' AS TIMESTAMP) - 60/1440e0 AND CAST('NOW' AS TIMESTAMP) 
>> >group by r.LINENR, r.COMPONENTNR
>> 
>> You forgot to mention the main part of any optimization task, the chosen 
>> PLAN. This answer is 
>> therefore based on expecting indexes not to be optimized for this query yet.
>> 
>> Is there any GRAVTIMESTAMP > 'NOW'? If not, then add a DESCENDING INDEX for 
>> GRAVTIMESTAMP and 
>> change your query to:
>> 
>> SELECT r.LINENR, r.COMPONENTNR, MAX(r.SUMWEIGHT)-MIN(r.SUMWEIGHT) as 
>> sumweightdiff FROM GRAVCOMPDATA_LONG r where r.GRAVTIMESTAMP >= 
>> CAST('NOW' AS TIMESTAMP) - 60/1440e0 group by r.LINENR, r.COMPONENTNR
>> 
>> Hopefully, this will change the PLAN and the execution time improve.
>> 
>> HTH,
>> Set

>Thanks a lot for this idea. I could reduce execution time tremendously:
>
>Executing...
>Done.
>11189 fetches, 45 marks, 5624 reads, 30 writes.
>0 inserts, 0 updates, 0 deletes, 1792 index, 0 seq.
>Delta memory: 23356 bytes.
>Total execution time: 0.296s
>Script execution finished.
>
>and yes there is no dedicated plan, and now I know I should give more 
>attention to the 
>chapter in hellens book ;-). Do you think that the additional index has an 
>notable effect 
>to the insertion time for the records ?.

No, I don't think this index should matter much for the insertion time, Jörn, 
timestamps tend to be quite selective. As for PLANs, you wouldn't normally 
write any PLAN, but the optimizer (which is part of executing your query) 
always generate PLANs for SELECTs and they are vital when it comes to 
understanding why a particular query is slow. Without the PLAN, guessing is 
often the best we can do (provided the query itself is the problem), with the 
PLAN, our guessing improves a lot.

Set

RE: [firebird-support] Improving execution time

[Svein Erling Tysvær]

>SELECT r.LINENR, r.COMPONENTNR, MAX(r.SUMWEIGHT)-MIN(r.SUMWEIGHT) as 
>sumweightdiff 
>FROM GRAVCOMPDATA_LONG r 
>where r.GRAVTIMESTAMP Between  CAST('NOW' AS TIMESTAMP) - 60/1440e0 AND 
>CAST('NOW' AS TIMESTAMP)
>group by r.LINENR, r.COMPONENTNR

You forgot to mention the main part of any optimization task, the chosen PLAN. 
This answer is therefore based on expecting indexes not to be optimized for 
this query yet.

Is there any GRAVTIMESTAMP > 'NOW'? If not, then add a DESCENDING INDEX for 
GRAVTIMESTAMP and change your query to:

SELECT r.LINENR, r.COMPONENTNR, MAX(r.SUMWEIGHT)-MIN(r.SUMWEIGHT) as 
sumweightdiff 
FROM GRAVCOMPDATA_LONG r 
where r.GRAVTIMESTAMP >= CAST('NOW' AS TIMESTAMP) - 60/1440e0 
group by r.LINENR, r.COMPONENTNR

Hopefully, this will change the PLAN and the execution time improve.

HTH,
Set

[firebird-support] Improving execution time

[joernheitland]

Hi everyone,

I am using FB 2.5.1 on Windows XP Prof. 
Flamerobin as Admin tool.

I have the following table, in which every minute and on every line, a record 
is inserted.

CREATE TABLE GRAVCOMPDATA_LONG
(
  LINENR integer NOT NULL,
  COMPONENTNR integer NOT NULL,
  GRAVTIMESTAMP timestamp NOT NULL,
  THROUGHPUTACT float,
  THROUGHPUTSET float,
  EXTRRPM float,
  SUMWEIGHT float,
  HOPPERWEIGHT float,
  CONSTRAINT INTEG_194 PRIMARY KEY (LINENR,COMPONENTNR,GRAVTIMESTAMP)
);

What I want to have is the following (e.g. the last hour)

LineNr ComponenNr SumWeightDifferences
1 1   257.470012
1 2   171.90
1 3   85.290001
1 4   8.49
1 5   17.08
1 6   25.66
2 1   518.069976
2 2   345.219987
2 3   173.059993
2 4   17.34
2 5   34.50
2 6   51.91

This is achieved by this select:

SELECT r.LINENR, r.COMPONENTNR, MAX(r.SUMWEIGHT)-MIN(r.SUMWEIGHT) as 
sumweightdiff
FROM GRAVCOMPDATA_LONG r where r.GRAVTIMESTAMP Between  CAST('NOW' AS 
TIMESTAMP) - 60/1440e0 AND CAST('NOW' AS TIMESTAMP)
group by r.LINENR, r.COMPONENTNR

Running this leads to:

Starting transaction...
Preparing query: SELECT r.LINENR, r.COMPONENTNR, 
MAX(r.SUMWEIGHT)-MIN(r.SUMWEIGHT) as sumweightdiff
FROM GRAVCOMPDATA_LONG r where r.GRAVTIMESTAMP Between  CAST('NOW' AS 
TIMESTAMP) - 60/1440e0 AND CAST('NOW' AS TIMESTAMP)
group by r.LINENR, r.COMPONENTNR
Prepare time: 0.016s
Field #01: GRAVCOMPDATA_LONG.LINENR Alias:LINENR Type:INTEGER
Field #02: GRAVCOMPDATA_LONG.COMPONENTNR Alias:COMPONENTNR Type:INTEGER
Field #03: . Alias:SUMWEIGHTDIFF Type:DOUBLE PRECISION
PLAN (R ORDER INTEG_194)

Executing...
Done.
7397933 fetches, 296 marks, 1889395 reads, 214 writes.
0 inserts, 0 updates, 0 deletes, 2463735 index, 0 seq.
Delta memory: 1784340 bytes.
Total execution time: 13.250s
Script execution finished.


My question is : How can I improve execution time ?


When I do a select with defined LINENR=1 and COMPONENTNR=1 like this :

SELECT r.LINENR, r.COMPONENTNR, MAX(r.SUMWEIGHT)-MIN(r.SUMWEIGHT) as 
sumweightdiff
FROM GRAVCOMPDATA_LONG r where r.GRAVTIMESTAMP Between  CAST('NOW' AS 
TIMESTAMP) - 60/1440e0 AND CAST('NOW' AS TIMESTAMP) and r.LINENR=1 and 
r.COMPONENTNR=1
group by r.LINENR, r.COMPONENTNR

then the execution time is 0.032s

Starting transaction...
Preparing query: SELECT r.LINENR, r.COMPONENTNR, 
MAX(r.SUMWEIGHT)-MIN(r.SUMWEIGHT) as sumweightdiff
FROM GRAVCOMPDATA_LONG r where r.GRAVTIMESTAMP Between  CAST('NOW' AS 
TIMESTAMP) - 60/1440e0 AND CAST('NOW' AS TIMESTAMP) and r.LINENR=1 and 
r.COMPONENTNR=1
group by r.LINENR, r.COMPONENTNR
Prepare time: 0.016s
Field #01: GRAVCOMPDATA_LONG.LINENR Alias:LINENR Type:INTEGER
Field #02: GRAVCOMPDATA_LONG.COMPONENTNR Alias:COMPONENTNR Type:INTEGER
Field #03: . Alias:SUMWEIGHTDIFF Type:DOUBLE PRECISION
PLAN (R ORDER INTEG_194 INDEX (INTEG_194))

Executing...
Done.
319 fetches, 0 marks, 0 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 102 index, 0 seq.
Delta memory: 25080 bytes.
Total execution time: 0.032s
Script execution finished.



Any help is appreciated.

Jörn

Re: [firebird-support] Generators, what could cause resetting generator values to some earlier version

[Sofija Blazevski]

This affected entire database (all generators actively in use), mostly 
generators are used for Integer columns, some are used for varchar 
columns in case like document number that has string prefix, the prefix 
can vary within a table.

I'm not sure how could type of column produce a problem like this?


Thanks,

- Sofija


On 10.8.2012 5:33, W O wrote:
> Which is the type of your column?
>
> It is Integer, Smallint, BigInt?
>
> Maybe that's the problem.
>
> Greetings.
>
> Walter.
>
>
>
>
> On Thu, Aug 9, 2012 at 5:50 AM, Sofija Blazevski <
> sofija.blazev...@grappologroup.com> wrote:
>
>> **
>>
>>
>>
>> On 8.8.2012 12:06, Mark Rotteveel wrote:
>>> On Wed, 08 Aug 2012 11:02:52 +0200, Sofija Blazevski
>>> >> > wrote:
 I did check user profiles, but didn't find any database copies there.

 Also, we don't administer this server, but currently we have access. So
 I noticed in system log a message for corrupt and unusable disk
 structure, though the message is from this morning(there was a power
 loss this morning) and problem has occurred on Monday, might this kind
 of problem be due to some kind of hardware failure?
>>> I was browsing my Firebird-support archive yesterday, and I did see
>>> somebody mentioning that depending on the (disk)cache configuration of
>>> Windows, changes might actually never be written out to disk, unless the
>>> file is actually closed by the application. If there was some kind of
>>> crash, this could mean that the changes were never actually written to
>>> disk.
>>>
>> That is very interesting to know about, thought I never had such case.
>>
>> Thank you for trying to help, it seems there are a lot of problems with
>> either system or hardware, as one of our application files, out of
>> nowhere came to filesize 0 and had to be replaced.
>>
>> - Sofija
>>
>>
>>> I am not sure what setting that would be though, and I do think it is
>>> highly unlikely that this would still happen in Windows.
>>>
>>> Mark
>>>
>>>
>> [Non-text portions of this message have been removed]
>>
>>   
>>
> [Non-text portions of this message have been removed]
>
>
>
> 
>
> ++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu.  Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++
> Yahoo! Groups Links
>
>
>
>



[Non-text portions of this message have been removed]