View Issue Details

IDProjectCategoryView StatusLast Update
0017360FPCDatabasepublic2013-06-13 07:00
ReporterJimBeam Assigned ToJoost van der Sluis  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformWindows 64 bitOSWindows 
Product Version2.4.3 
Fixed in Version2.6.0 
Summary0017360: Firebird database exceptions don't generate EIBDatabaseError but a general exception on 64 bit windows
DescriptionRunning a query that e.g. inserts a duplicate value for a table with a unique index leads to a database exception on 32 bit Windows. On 64 bit Windows, the database exception is not caught, but a general exception is caught instead.

Please see fbembedtest_readme.txt in attached zip files.
Steps To ReproduceAttached are 2 projects, a 32 bit and 64 bit Windows version. They contain the respective embedded Firebird libraries and a database. Please (compile and) run the fbembedtest.exe executables to reproduce.
The program will insert a numeric value (5) into a table with a unique index. Later on it will try to insert the same number which will lead to a database exception, which is correctly handled by the 32 bit version but not by the 64 bit version. Finally, a custom Firebird exception message is triggered on inserting the value 13, which leads to an apparent hang in the application on 64 bit.
Please see fbembedtest_readme.txt in the attached zip file for more details. Due to size constraints on the upload file, please manually download the firebird embedded clients (see fbembedtest_readme.txt)
Additional InformationOriginally ran this with FreePascal 2.4.1; now compiled with 2.4.3, using the 2.4.1 database source files (the change dates for the files involved haven't changed.)
Maybe this bug has something to do with bug 0017280 as at least the error message is the same and FreePascal is using the Firebird client dll which is coded in C++.
Tags64bit, Database, Exception
Fixed in Revision16586
FPCOldBugId0
FPCTarget
Attached Files

Relationships

related to 0024012 closedSergei Gorelkin Enable Win64 SEH by default so exceptions in DLLs can properly be caught 

Activities

2010-09-06 16:05

 

fbembedtest.zip (1,319,385 bytes)

JimBeam

2010-09-07 12:30

reporter   ~0040883

A full download containing all required Firebird dlls/files is available at
http://bitbucket.org/jb/flocate/issue/6/firebird-database-exceptions-dont-generate-eibdatabaseerror-but-a-general-exception-on-64-bit

Marco van de Voort

2010-09-07 12:53

manager   ~0040884

EIBDatabaseError is not a caught C++ exception. It is simply a error raised when an error is detected via the usual status and isc_interprete handling.

Most probably, there is simply a bug in the 64-bit firebird that raises an exception that is indeed not caught by FPC. But that is a Firebird, not a FPC issue.

JimBeam

2010-09-09 07:04

reporter   ~0040910

Thanks, I'll try some other versions of Firebird and get in touch with the Firebird community to see whether they've got ideas.

JimBeam

2010-09-14 07:38

reporter   ~0041051

Different behaviour depending on Firebird client dll - assuming it crashes in different stages.
E.g.: insertion of 13 to generate custom exception doesn't have hang as on 2.1 but gives a ctrl-c pressed error for recent Firebird 2.5/3.0 snapshots.

For server x32 Linux 2.1.3.18185 (stable), Windows client lib 3.0 snapshot (Firebird-3.0.0.28557-0_x64.7z): gives NO error on duplicate insertion (simply SaveNumber: insert query code done. on inserting 13 we do get a ctrl c error.

On Ubuntu x64 (2.6.32-24-generic 0000041-Ubuntu SMP Thu Aug 19 01:38:40 UTC 2010 x86_64 GNU/Linux
) after symlinking libfbclient.so in local dir to relevant version in app dir (some beta or RC form of the upcoming 2.5.0 version):
This now gives proper output comparable to the 32 bit version - confirming the problem probably doesn't exist on Linux but Windows.
See
http://bitbucket.org/jb/flocate/issue/6/firebird-database-exceptions-dont-generate-eibdatabaseerror-but-a-general-exception-on-64-bit
for output etc.

Next step: get Firebird debug build at least for stable 2.1.3 version, create backtrace.

JimBeam

2010-09-17 10:51

reporter   ~0041163

Couldn't create backtrace as FPC uses GDB; Firebird uses PDB/Microsoft debugger. Don't have the experience to figure it out.

Vlad Khorsun from the Firebird project had a quick look at the ibase* code and suggested ISC_STATUS should be the size of a pointer => 8 bytes on 64 bits: http://groups.yahoo.com/group/firebird-support/message/109974;_ylc=X3oDMTJzNnBhbTg2BF9TAzk3MzU5NzE1BGdycElkAzI0NDI0MDYEZ3Jwc3BJZAMxNzA1MTE1Mzg2BG1zZ0lkAzEwOTk3NARzZWMDZG1zZwRzbGsDdm1zZwRzdGltZQMxMjg0NTQzMzU4
(Further discussion to be done on the fb-devel list).
Changed this and some others in ibase60.inc and ibase40.pp (search for comments with jb) based on the definitions in ibase.h (Firebird 2.1 x64) (attached; also uploaded iberror.h), but this in itself is not enough to avoid crashes, so there might be more.
I don't have the knowledge yet to figure out what else to change. I'll need help from people more experienced with C++ and FreePascal.

2010-09-17 10:52

 

ibase.h (89,955 bytes)

2010-09-17 10:52

 

iberror.h (107,495 bytes)

2010-09-17 10:53

 

ibase40.pp (74,663 bytes)

2010-09-17 10:53

 

ibase60.inc (119,253 bytes)

JimBeam

2010-12-14 13:05

reporter   ~0044222

Last edited: 2010-12-14 13:07

Further discussion on fb-devel, thanks to Martin Schreiber/Alex Peshkoff.
See
http://sourceforge.net/mailarchive/forum.php?forum_name=firebird-devel&viewmonth=201012
Changed these files:
--- ibase60_original.inc Sun Jan 17 12:33:38 2010
+++ ibase60.inc Tue Dec 14 13:28:50 2010
@@ -33,7 +33,12 @@
    ISC_UCHAR = cuchar;
    ISC_SHORT = cshort;
    ISC_USHORT = cushort;
- ISC_STATUS = clong;
+ //original:
+ //ISC_STATUS = clong;
+ //jb: based on suggestion by Vlad
+ //http://tech.groups.yahoo.com/group/firebird-support/message/109974
+ //changed to 4 byte on 32 bit and 8 byte on 64 bit:
+ ISC_STATUS = PtrInt;
    ISC_INT64 = clonglong;
    ISC_UINT64 = culonglong;
 {$IFDEF CPU64}
and
--- ibase40_original.pp Sat Jan 26 14:53:13 2008
+++ ibase40.pp Mon Dec 13 08:50:47 2010
@@ -45,7 +45,12 @@
 
   ISC_LONG = Long;
   UISC_LONG = ULong;
- ISC_STATUS = Long;
+ //original code:
+ //ISC_STATUS = Long;
+ //jb: based on suggestion by Vlad
+ //http://tech.groups.yahoo.com/group/firebird-support/message/109974
+ //changed to 4 byte on 32 bit and 8 byte on 64 bit:
+ ISC_STATUS = PtrInt;
   UISC_STATUS = ULong;
   Void = Pointer;
   PISC_LONG = ^ISC_LONG;

Results
- windows x64
- inserting duplicate value in unique constraint still gives crash
- closing database connection now works instead of crashing as in original code

Still discussing further on fb-devel; suggestions for further help welcome.

Martin Schreiber

2010-12-15 09:19

reporter   ~0044231

Please test if every DB error results in a general exception. What exception happens actually? Please set a breakpoint to the statement which returns the error, step through the code until the exceptions happens.
I can not test myself because I don't have win64.

JimBeam

2010-12-15 14:21

reporter   ~0044234

Martin, thanks for the help.

1. Does every DB error result in a general exception?
Seems so. I've added an insert in a non-existing table which gives the same result. Pls see the gdb run R1 below.

2. What exception happens actually?
I've added the exception class to the output; EControlC

3. Breakpoints:
Can't seem to manage to debug properly in Lazarus right now. Marco van de Voort indicated above the error probably occurs in the Firebird code.
My debugging skills are not that *cough* good.
ATM, my Lazarus x64 doesn't seem to want to debug while running the gdb debugger on the generated exe.
Tried gdb.exe on exe compiled with -g -gl -gh -gw (see R3) - now it really crashes after generating some control-c errors.

4. Server DOES work
However, having the test program talk to a server on a different machine, using the same fbembed.dll, DOES work.
Please see R2 below.
So it must be something in the way FPC passes data to the Firebird DLL, which the DLL doesn't like ONLY in an embedded situation.
Very strange. Shouldn't somebody from the Firebird end look at this (preferably with better skills than mine)?

Please find below some gdb runs: R1, R3 on the embedded test program, R2 on the same program slightly changed to use a 2.x x64 server (on a different machine).

R1: Embedded test program (compiled with fpc -g -gl -gh):
D:\Cop\embed64>gdb fbembedtest.exe
GNU gdb 6.7.50.20080109-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-mingw32"...

warning: A handler for the OS ABI "Cygwin" is not built into this configuration
of GDB. Attempting to continue with the default i386:x86-64 settings.

*** Loaded read_coff
(no debugging symbols found)
(gdb) run
Starting program: D:\Cop\embed64/fbembedtest.exe
<snip details>
*** First, clear any existing numbers out of database:
Debug: 15-12-2010 14:45:35: ClearData: going to run query DELETE FROM NUMBERS;

Debug: 15-12-2010 14:45:35: ClearData: query code done.
*** Executing an insert query with the wrong table, should give a db error:
Debug: 15-12-2010 14:45:35: RunSQL: going to run query INSERT INTO THISTABLEDOES
NTEXIST (BINGONUMBER) VALUES (91)

Debug: 15-12-2010 14:45:35: RunSQL: exception running delete query. Exception me
ssage: Control-C hitException type: EControlC
*** Executing a simple insert query without parameters:
Debug: 15-12-2010 14:45:35: RunSQL: going to run query INSERT INTO NUMBERS (BING
ONUMBER) VALUES (91);

Debug: 15-12-2010 14:45:35: RunSQL: query code done.
*** Executing a simple insert query without parameters for the same value. This
should fail:
Debug: 15-12-2010 14:45:35: RunSQL: going to run query INSERT INTO NUMBERS (BING
ONUMBER) VALUES (91);

Debug: 15-12-2010 14:45:35: RunSQL: exception running delete query. Exception me
ssage: Control-C hitException type: EControlC
*** Executing a simple delete query without parameters:
Debug: 15-12-2010 14:45:35: RunSQL: going to run query DELETE FROM NUMBERS WHERE
 BINGONUMBER=91;


Program received signal SIGSEGV, Segmentation fault.
0x000000007780592a in ?? ()
(gdb) bt
#0 0x000000007780592a in ?? ()
0000001 0x000000000102f170 in ?? ()
0000002 0x0000000000000200 in ?? ()
0000003 0x00000000010ac088 in ?? ()
0000004 0x0000000002efe020 in ?? ()
0000005 0x000000000102f170 in ?? ()
0000006 0x0000000000000000 in ?? ()

R2: Server test program (compiled with fpc -g -gl -gh):
D:\Cop\embed64>gdb fbservertest.exe
GNU gdb 6.7.50.20080109-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-mingw32"...

warning: A handler for the OS ABI "Cygwin" is not built into this configuration
of GDB. Attempting to continue with the default i386:x86-64 settings.

*** Loaded read_coff
(no debugging symbols found)
(gdb) run
Starting program: D:\Cop\embed64/fbservertest.exe
<snip details>
Debug: 15-12-2010 14:47:03: Application started.

*** First, clear any existing numbers out of database:
Debug: 15-12-2010 14:47:03: ClearData: going to run query DELETE FROM NUMBERS;

Debug: 15-12-2010 14:47:03: ClearData: query code done.
*** Executing an insert query with the wrong table, should give a db error:
Debug: 15-12-2010 14:47:03: RunSQL: going to run query INSERT INTO THISTABLEDOES
NTEXIST (BINGONUMBER) VALUES (91)

Debug: 15-12-2010 14:47:03: Database error running delete query. Database error
message: : PrepareStatement :
 -Dynamic SQL Error
 -SQL error code = -204
 -Table unknown
 -THISTABLEDOESNTEXIST
 -At line 1, column 13; Database error code: 335544569
*** Executing a simple insert query without parameters:
Debug: 15-12-2010 14:47:03: RunSQL: going to run query INSERT INTO NUMBERS (BING
ONUMBER) VALUES (91);

Debug: 15-12-2010 14:47:03: RunSQL: query code done.
*** Executing a simple insert query without parameters for the same value. This
should fail:
Debug: 15-12-2010 14:47:03: RunSQL: going to run query INSERT INTO NUMBERS (BING
ONUMBER) VALUES (91);

Debug: 15-12-2010 14:47:03: Database error running delete query. Database error
message: : Execute :
 -violation of PRIMARY or UNIQUE KEY constraint "NUMBERUNIQUE" on table "NUMBERS
"; Database error code: 335544665
*** Executing a simple delete query without parameters:
Debug: 15-12-2010 14:47:03: RunSQL: going to run query DELETE FROM NUMBERS WHERE
 BINGONUMBER=91;

Debug: 15-12-2010 14:47:03: RunSQL: query code done.
*** Insert number 5. This should work:
Debug: 15-12-2010 14:47:03: SaveNumber: going to add parameters for insert query

Debug: 15-12-2010 14:47:03: SaveNumber: going to execute the insert query.
Debug: 15-12-2010 14:47:03: SaveNumber: insert query code done.
*** Insert number 5 again. This should fail because of the unique index.
*** We should get a generic database error.
Debug: 15-12-2010 14:47:03: SaveNumber: going to add parameters for insert query

Debug: 15-12-2010 14:47:03: SaveNumber: going to execute the insert query.
Debug: 15-12-2010 14:47:03: Database error running query. Database error message
: : Execute :
 -violation of PRIMARY or UNIQUE KEY constraint "NUMBERUNIQUE" on table "NUMBERS
"; Database error code: 335544665
Debug: 15-12-2010 14:47:03: Parameters were:
BINGONUMBER: *5*
Debug: 15-12-2010 14:47:03: Rolling back transaction.
Debug: 15-12-2010 14:47:03: SaveNumber: insert query code done.
*** Now test our custom Firebird exception by trying to insert 13:
Debug: 15-12-2010 14:47:03: SaveNumber: going to add parameters for insert query

Debug: 15-12-2010 14:47:03: SaveNumber: going to execute the insert query.
Debug: 15-12-2010 14:47:03: SaveNumber: insert query code done.
*** Ok, done. Let's close down the connection
Debug: 15-12-2010 14:47:03: Application finished.
Debug: 15-12-2010 14:47:03: Destroy: Going to commit active transaction.
Debug: 15-12-2010 14:47:03: Destroy: Transaction committed.
Debug: 15-12-2010 14:47:03: FreeAll: Disconnecting from database.

Program exited normally.
(gdb) bt

R3 Embedded exe compiled with -g -gl -gh -gw
Starting gdb:
GNU gdb 6.7.50.20080109-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-mingw32"...

warning: A handler for the OS ABI "Cygwin" is not built into this configuration
of GDB. Attempting to continue with the default i386:x86-64 settings.
(gdb) break 77
invalid dwarf2 offset 938135
(gdb) run
Starting program: D:\Cop\embed64/fbembedtest.exe
Debug: 15-12-2010 15:11:41: Starting database setup:
<snip details>
*** First, clear any existing numbers out of database:
Debug: 15-12-2010 15:11:41: ClearData: going to run query DELETE FROM NUMBERS;

Debug: 15-12-2010 15:11:41: ClearData: query code done.
*** Executing an insert query with the wrong table, should give a db error:
Debug: 15-12-2010 15:11:41: RunSQL: going to run query INSERT INTO THISTABLEDOES
NTEXIST (BINGONUMBER) VALUES (91)

Debug: 15-12-2010 15:11:41: RunSQL: exception running delete query. Exception me
ssage: Control-C hitException type: EControlC
*** Executing a simple insert query without parameters:
Debug: 15-12-2010 15:11:41: RunSQL: going to run query INSERT INTO NUMBERS (BING
ONUMBER) VALUES (91);

Debug: 15-12-2010 15:11:41: RunSQL: query code done.
*** Executing a simple insert query without parameters for the same value. This
should fail:
Debug: 15-12-2010 15:11:41: RunSQL: going to run query INSERT INTO NUMBERS (BING
ONUMBER) VALUES (91);

Debug: 15-12-2010 15:11:41: RunSQL: exception running delete query. Exception me
ssage: Control-C hitException type: EControlC
*** Executing a simple delete query without parameters:
Debug: 15-12-2010 15:11:41: RunSQL: going to run query DELETE FROM NUMBERS WHERE
 BINGONUMBER=91;


Program received signal SIGSEGV, Segmentation fault.
0x000000007780592a in ?? ()
(gdb) bt
#0 0x000000007780592a in ?? ()
0000001 0x000000000102f170 in ?? ()
0000002 0x0000000000000200 in ?? ()
0000003 0x000000000153c088 in ?? ()
0000004 0x0000000002f0e020 in ?? ()
0000005 0x000000000102f170 in ?? ()
0000006 0x0000000000000000 in ?? ()
(gdb)

Marco van de Voort

2010-12-18 13:37

manager   ~0044330

It makes sense. On 64-bit systems clong is 64-bit on Unix, and NOT on win64, as there clonglong is a 64-bit type. (LP64 vs LLP64)

committed it (with trimmed comments refering to this report)

JimBeam

2010-12-20 16:51

reporter   ~0044437

Marco, thanks for the applied patch. It does fix the problem with database disconnects, however, it does not fix the access violations when running SQL that references non-existent tables, SQL that enters duplicate values in unique indexes, i.e. perform things that you should get a normal error message instead of an access violation.
Of course, my test code may be at fault, but it runs well on win32/firebird 32 bit embedded, as well as on win64/firebird 64 bit separate server.
Firebird probably doesn't like something that we're passing it.
I'll ask on the Firebird-devel list to run the test code to see if something is obviously wrong with that.

Marco van de Voort

2010-12-20 17:38

manager   ~0044438

I'm not a FB user. I just committed the header patch.

If I were, I would review the header to see if there were more similar cases.

JimBeam

2010-12-21 12:47

reporter   ~0044462

Last edited: 2010-12-21 12:50

It appears FPC Win64 is not dealing well with exceptions in DLL code? And it seems this is indeed the same problem as mentioned in bug 17280...
Why?
On the firebird-devel list, Vlad Khorsun kindly ran a debugger and came to the following conclusion:

Vlad:
I tried Jim's executable and run it under VC8 debugger in IDE. Target was fbembed.dll
and Jim's executable was used as host application. What is wondered me is that while debugger was able to catch Firebird's internal exceptions, it never can continue debugging at point when exception catched in code or re-throwed. This forced me to look how exception handling implemented in FPC.

    I'm not an expert in exception handling internals so below i could be wrong.

    The interesting code for Win64 is at

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/win64/system.pp?revision=16472&view=markup


    Note, it used Vectored Exception Handling technique :

  871 procedure install_exception_handlers;
  872 begin
  873 AddVectoredExceptionHandler(1,@syswin64_x86_64_exception_handler);
  874 end;


Exception handler (syswin64_x86_64_exception_handler) code is at few lines above.

    Note comment at line 837:

  834 if ((excep^.ExceptionRecord^.ExceptionCode and SEVERITY_ERROR) = SEVERITY_ERROR) then
  835 err := 217
  836 else
  837 { pass through exceptions which aren't an error. The problem is that vectored handlers
  838 always are called before structured ones so we see also internal exceptions of libraries.
  839 I wonder if there is a better solution (FK)
  840 }

    So, you see - FPC application handled exception *before* Firebird library.

    As i understand code, it handles MSVC's internal exceptions, convert it into Pascal run-time error 217 (Control-C) and exits with EXCEPTION_CONTINUE_EXECUTION. This gives no chance for Firebird library to handle exception correctly. Also it explains messages about "Ctrl-C hit" in Jim's application output.

    I compared it with 32-bit code. Look at
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/win32/system.pp?revision=16472&view=markup

    It used usual Frame-based Exception Handling technique and its handler works for unhandled exceptions
only, allowing Firebird library to catch and handle its internal exceptions :

786 procedure install_exception_handlers;
...
801 SetUnhandledExceptionFilter(@syswin32_i386_exception_handler);


    Should i add that Firebird handle all of its internal exceptions by itself ? :)

Hope this helps,
Vlad

Marco van de Voort

2011-10-25 11:54

manager   ~0053411

Last edited: 2011-10-25 11:54

Maybe calling the said function from a safecall procedure works?

Reinier Olislagers

2012-06-21 09:24

developer   ~0060637

Using the Win64 SEH patch fixes this problem:

fbembed.dll x64 2.5.0.26074

1. Compiled FPC r21666 with -gw -gl
Test program failed: Firebird database exceptions are incorrectly seen as general exceptions. Output extract:
*** Insert number 5 again. This should fail because of the unique index.
*** We should get a generic database error.
Debug: 21-6-2012 11:15:23: SaveNumber: going to add parameters for insert query
Debug: 21-6-2012 11:15:23: Error running insert query. Technical details: Control-C hit

*** Now test our custom Firebird exception by trying to insert 13:
Debug: 21-6-2012 11:15:23: SaveNumber: going to add parameters for insert query
Debug: 21-6-2012 11:15:23: Error running insert query. Technical details: Control-C hit

2. Compiled FPC r21666 with -gw -gl -dTEST_WIN64_SEH
Test program succeeded: we correctly get database exceptions. Output extract:
*** Insert number 5 again. This should fail because of the unique index.
*** We should get a generic database error.
Debug: 21-6-2012 11:22:12: SaveNumber: going to add parameters for insert query
Debug: 21-6-2012 11:22:12: Database error running insert query. Database error message: : Execute :
 -violation of PRIMARY or UNIQUE KEY constraint "NUMBERUNIQUE" on table "NUMBERS"; Database error code: 335544665
 
*** Now test our custom Firebird exception by trying to insert 13:
Debug: 21-6-2012 11:22:12: SaveNumber: going to add parameters for insert query
Debug: 21-6-2012 11:22:12: Database error running insert query. Database error message: : Execute :
 -exception 1
 -EXCNOT13
 -No, not 13, I can't handle that!
 -At trigger 'TRIGCHECK13' line: 7, col: 28; Database error code: 335544517

Marco van de Voort

2013-03-08 18:33

manager   ~0066123

SEH is now default in 2.7.x, please test it.

Issue History

Date Modified Username Field Change
2010-09-06 16:05 JimBeam New Issue
2010-09-06 16:05 JimBeam Status new => assigned
2010-09-06 16:05 JimBeam Assigned To => Joost van der Sluis
2010-09-06 16:05 JimBeam File Added: fbembedtest.zip
2010-09-06 16:06 JimBeam Tag Attached: 64bit
2010-09-06 16:06 JimBeam Tag Attached: Database
2010-09-06 16:06 JimBeam Tag Attached: Exception
2010-09-07 12:30 JimBeam Note Added: 0040883
2010-09-07 12:49 Marco van de Voort FPCOldBugId => 0
2010-09-07 12:49 Marco van de Voort Additional Information Updated
2010-09-07 12:53 Marco van de Voort Note Added: 0040884
2010-09-09 07:04 JimBeam Note Added: 0040910
2010-09-14 07:38 JimBeam Note Added: 0041051
2010-09-17 10:51 JimBeam Note Added: 0041163
2010-09-17 10:52 JimBeam File Added: ibase.h
2010-09-17 10:52 JimBeam File Added: iberror.h
2010-09-17 10:53 JimBeam File Added: ibase40.pp
2010-09-17 10:53 JimBeam File Added: ibase60.inc
2010-12-14 13:05 JimBeam Note Added: 0044222
2010-12-14 13:07 JimBeam Note Edited: 0044222
2010-12-15 09:19 Martin Schreiber Note Added: 0044231
2010-12-15 14:21 JimBeam Note Added: 0044234
2010-12-18 13:37 Marco van de Voort Fixed in Revision => 16586
2010-12-18 13:37 Marco van de Voort Status assigned => resolved
2010-12-18 13:37 Marco van de Voort Fixed in Version => 2.5.1
2010-12-18 13:37 Marco van de Voort Resolution open => fixed
2010-12-18 13:37 Marco van de Voort Note Added: 0044330
2010-12-20 16:51 JimBeam Status resolved => feedback
2010-12-20 16:51 JimBeam Resolution fixed => reopened
2010-12-20 16:51 JimBeam Note Added: 0044437
2010-12-20 17:38 Marco van de Voort Note Added: 0044438
2010-12-21 12:47 JimBeam Note Added: 0044462
2010-12-21 12:50 JimBeam Note Edited: 0044462
2011-10-25 11:54 Marco van de Voort Note Added: 0053411
2011-10-25 11:54 Marco van de Voort Note Edited: 0053411
2012-06-21 09:24 Reinier Olislagers Note Added: 0060637
2013-03-07 17:16 Reinier Olislagers Relationship added related to 0024012
2013-03-08 18:33 Marco van de Voort Note Added: 0066123
2013-03-08 18:33 Marco van de Voort Status feedback => resolved
2013-03-08 18:33 Marco van de Voort Resolution reopened => fixed
2013-06-13 07:00 JimBeam Status resolved => closed