Firebird 2.1 final release

[mdaems]

Not as far as I know... You have some interest? I guess the others in this thread would be best candidates to do it. So Firebird boys (no girls present?), show us what you can do...

Mark

[patyi]

Hi,

A simple work a round for connecting to Firebird 2.1
First time you have to open tvice the query...

Connection.Connect;
if Connection.Connected then begin
try
Query.Open; // firs time is error
except
Query.Open; // second tim is success
end;
end;

error occures only in design time ...

My investigation has no result et a moment what is the problem with protocol ... to bee continued ...

[andrevanzuydam]

After looking at the API changes and considering the changes in Firebird 2.1 I think it would be good to list a new protocol in the Zeos protocol drop down list and move from there. I've noticed also new dependancies in PHP which are now needed to compile support for Firebird 2.1 into PHP.

I have started yesterday to rework the API - is there perhaps someone who is maybe ahead of me or wants to help in this excercise - perhaps we could work on different sections.

The easiest method to debug this is to create a small application to duplicate the errors and work from there to test a "new" protocol.

The workaround suggested above causes segmentation fault in a kylix application we have also compiled with zeos so I can't use it as a solution, It would be good to get to the bottom of the problem. My immediate thoughts due to the Linux error is that there is a call to some function that has been discontinued.

[andrevanzuydam]

Here is some debugger information when one tries to run the Open method on a TZQuery. Any thoughts ?

New exception:
Exception code: 3221225477
Exception flags: 2
Number of parameters: 2
(no debug info) Find error: 00000000
call stack - 0 : Routine @System@@IntfClear Find error: 00406A67
call stack - 1 : Module ZDbcResultSetMetadata.pas Routine @Zdbcresultsetmetadata@TZAbstractResultSetMetadata@GetTableColumns Line 547 Find error: 0046DB61
call stack - 2 : Module ZDbcResultSetMetadata.pas Routine @Zdbcresultsetmetadata@TZAbstractResultSetMetadata@ReplaceStarColumns Line 708 Find error: 0046E04B
call stack - 3 : Module ZDbcResultSetMetadata.pas Routine @Zdbcresultsetmetadata@TZAbstractResultSetMetadata@LoadColumns Line 747 Find error: 0046E183
call stack - 4 : Module ZDbcResultSetMetadata.pas Routine @Zdbcresultsetmetadata@TZAbstractResultSetMetadata@IsWritable Line 493 Find error: 0046DA4F
call stack - 5 : Module ZAbstractRODataset.pas Routine @Zabstractrodataset@TZAbstractRODataset@InternalOpen Line 1595 Find error: 00523745
call stack - 6 : Routine @Db@TDataSet@DoInternalOpen Find error: 005101EF
call stack - 7 : Routine @Db@TDataSet@Open Find error: 0050FFAE
call stack - 8 : Routine @Controls@TWinControl@WndProc Find error: 0043DDD8
call stack - 9 : Routine @Controls@DoControlMsg Find error: 0043DF10
call stack - 10 : Routine @Controls@TWinControl@WndProc Find error: 0043DDD8
call stack - 11 : Routine @Controls@TWinControl@MainWndProc Find error: 0043DA53
call stack - 12 : Routine @Classes@StdWndProc Find error: 0042693A
call stack - 13 : (no debug info) Find error: 7E418720
call stack - 14 : (no debug info) Find error: 7E418802
call stack - 15 : (no debug info) Find error: 7E41B887
call stack - 16 : (no debug info) Find error: 7E41B8EF
call stack - 17 : (no debug info) Find error: 7E44FE91
call stack - 18 : (no debug info) Find error: 7E446589
call stack - 19 : (no debug info) Find error: 7E42783B
call stack - 20 : (no debug info) Find error: 7E43B066
call stack - 21 : (no debug info) Find error: 7E418720
call stack - 22 : (no debug info) Find error: 7E418802
call stack - 23 : (no debug info) Find error: 7E41C61F
call stack - 24 : (no debug info) Find error: 7E41E8E1
call stack - 25 : Routine @Controls@TWinControl@DefaultHandler Find error: 0043DEBC
call stack - 26 : Routine @Controls@TWinControl@WndProc Find error: 0043DDD8

[mdaems]

@andré,

Nobody is working on a FB2.1 driver yet, as far as I know. So ... you can go on.

Maybe check what changed first before you start coding. If it's possible to stick to one FB 2 driver that's better, of course.

I don't know much about how the FB drivers are written, but main lesson I learned with mysql drivers is to avoid using converted C-structures (= pascal records) to access data returned from the dll. Use API functions resulting single values if that is possible. Example : see SVN Rev. 373 as fix for mysql 5.1 compatibility bug 113. This way it was not necessary to have different 5.0 and 5.1 drivers just because mysql decided to change some record structure.

Concerning the error : looks like a problem when calling overridden class methods through an interface. No idea what to do about that.

Mark

[andrevanzuydam]

Hi Mark

I have completed the new references to the API and the new constants and tried to debug the existing code. One concern I have is that there are many calls to the same code (regarding field lookups and populating cache which seem to take up way too much time and creates the memory problems). I think the problem lies in the population of field properties and the relevant calls to some isc info routine.

Thanks for the point in the right direction - I will take a look at the mysql API.

I will try my best to put out a driver for 2.1 and welcome any help and debugging.

Andre

[seawolf]

Hi everybody,

here:http://digilander.libero.it/pellegrinol ... 21-src.zip you can found what 've done until now. Anyway the problem still remain.

I've also add a folder under lib/firebird etc. with the embedded version of firebird 2.1

Ciccio

[andrevanzuydam]

Hi Seawolf

Please confirm the size of your zip - can't seem to get the full download.

Thanks for the effort

[mdaems]

I got 23.804 bytes. No lib directory included. archive tested OK.

@ andrevanzuydam ,
How do you think we best go on? Do you merge the work both of you did so we can add a first version to SVN? (eventually including bugs, doesn't matter, so we can all have a look at them)

@ seawolf,
Can you add a new link to your post with the things you added to the lib directory? (client server version and embedded version?

Mark

[andrevanzuydam]

Im busy checking out the latest SVN - I've never really worked in team before - I'm busy looking at docs etc to setup test environment - otherwise might mess up my production system

Any suggestions will be welcome.

[andrevanzuydam]

Ok looks like we're doing duplicate work ... One error though

isc_interprete := GetAddress('fb_interpret'); // not fb_interprete

Otherwise looks great.

The new function fb_interpret() replaces the former isc_interprete() for extracting the text for a Firebird
error message from the error status vector to a client buffer.

Should be continue the isc naming convention or should we now declare fb_interpret := GetAddress ...

[mdaems]

If it's on the same machine I would advise to run the test environment in a Virtual Machine or use Lazarus instead of Delphi (assuming you're not using Lazarus in production). My experience is that it's extremely difficult to keep different versions for 100% separated in a Delphi environment. (Also in Lazarus but if you don't use that in production that's not an issue.)

If you want to use the test suite you'll have to use Delphi. However, that system uses a nice sandbox approach. So you can run the build/tests without interfering with your production installation by setting the build targets outside your production paths. IDE integrations should not be necessary just to run the test suite. (I'm running the tests against 3 delphi compilers in 1 run without interference)
Test suite documentation (only slightly outdated) is available in the documentation/articles_generated directory.

Concerning the naming schema : That's mostly up to you. Inside the 'plain' level I would say : use different names (I suppose both functions are still available in the library?) But I think exposing the new function to the dbc level only makes sense when you must handle the functions different on the dbc level anyway. Like

Code: Select all

If FB21 then 
    begin  
       A;
       Plain.FB_interprete;
       B;
   end
else
   begin
       old_A;
       Plain.isc_interprete;
       old_B;
   end;

If in this example A=old_a and B=old_b just stick to the current plaindriver interface.

Mark

[andrevanzuydam]

The code internal to this procedure seems to be causing the memory error:

TZInterbase6DatabaseMetadata.GetColumns

Particularly the code within the loop:

while GetConnection.CreateStatement.ExecuteQuery(SQL) do

So it seems logical to me if we debug whats going on in here we will eliminate the error.

[seawolf]

Here u can found the firebird 2.1 lib dir http://digilander.libero.it/pellegrinol ... .17798.zip (copy it to lib/firebird/windows/23bit/2.1.0.17798)

Today I do some changes to the tests: here http://digilander.libero.it/pellegrinol ... 050608.zip I change test.properties add an item regarding firebird (embedded). By this way some tests works (but the majority not)

Edit: please remove create_firebird21.sql cause does not work properly (use instead create_interbase.sql) Sorry

[andrevanzuydam]

Thanks for the code - I'm going to put some more time in tomorrow on this one. Any clues to what is causing the memory problems?

Some things to think about --- Extra functionality in the new Firebird

1.) The insert statements can return the value of an inserted range of records

2.) The name of generators has changed to sequence & autoincrement should be done with fetch next value for <sequence>

3.) Temporary tables (Perhaps we can also test that they work too ?) We must add the new reserved words also into the definitions.