firebird-odbc-devel — All about development of Firebird ODBC driver donated by IBPhoenix

Re: [Firebird-odbc-devel] [Suspected Spam] Re: Firebird ODBC: x64data lengthcompatibility

[Nikolay S. <nik...@re...>]

Andrei,

Engineering wrote:
>
> I found the JIRA tracker after a while (did submit a SQL_BIT support 
> patch in the mean time there) .. however that was quite hard to find 
> and I found the ODBC devel list instead. Since I got the message from 
> Nikolay that the patch was applied to 2.0, I guess I can skip the 
> posting in the tracker, however I will add any new patches there. 
> Thank you for the info.
>
> What are firebird developers likely to check – the devel list or the 
> tracker? The tracker seems to have few issues, but some of them seem 
> really ancient.
>
Myself and other guys from our lab (e.g. Roman Simakov) I know read odbc 
devel mailing list regularly. However if everyone is busy, some messages 
may be left unprocessed.
If an item is posted to the tracker only it will get some attention for 
sure, but it is checked less frequently.

Re SQL_BIT, I may apply this patch to HEAD. But could you please attach 
patch file to an issue instead of placing it inline as comments - it 
does not apply cleanly at this moment.

> Regards,
>
> Andrei
>


-- 
Nikolay Samofatov, MBA
Red Soft Corporation
+1 416 710 6854
+7 495 721 3537

Re: [Firebird-odbc-devel] [Suspected Spam] Re: Firebird ODBC: x64data lengthcompatibility

[Engineering <eng...@as...>]

    I found the JIRA tracker after a while (did submit a SQL_BIT support patch in the mean time there) .. however that was quite hard to find and I found the ODBC devel list instead. Since I got the message from Nikolay that the patch was applied to 2.0, I guess I can skip the posting in the tracker, however I will add any new patches there. Thank you for the info.

  What are firebird developers likely to check - the devel list or the tracker? The tracker seems to have few issues, but some of them seem really ancient.

 

Regards,

Andrei

 

From: Jorge Andres Brugger [mailto:jor...@gm...] 
Sent: Wednesday, April 22, 2009 7:31 PM
To: fir...@li...
Subject: [Suspected Spam] Re: [Firebird-odbc-devel] Firebird ODBC: x64data lengthcompatibility

 

Just FYI, Firebird ODBC has a tracker, located at http://tracker.firebirdsql.org/browse/ODBC

Could be a good idea to report the problem and attach the patch there. 

Regards

Engineering escribió: 

Attached is an updated patch that replaces some more indicator pointers with SQLLEN pointers. Behavior seems much better (i.e. selects with and without parameters seem to work on Win64), however I did by no means go through an exhaustive test.
 
Andrei
 
-----Original Message-----
From: Engineering [mailto:eng...@as...] 
Sent: Thursday, April 09, 2009 2:08 PM
To: fir...@li...
Subject: Re: [Firebird-odbc-devel] Firebird ODBC: x64 data lengthcompatibility
 
I did some further tests .. the attached patch seems to fix the selection but not the prepared statement section (driver crashes with a corrupted heap on statement release). It seems to me that the code assumes that sizeof(long) == 8, which in windows it is not true. On SQLDa.cpp, we have:
....
        offset = ROUNDUP (offset, sizeof (int));
        indicatorsOffset = offset;
        offset += sizeof(long) * numberColumns;
        buffer = new char [offset];
        lengthBufferRows = offset;
....
 
And the part that states sizeof(long) should probably be updated to sizeof(SQLLEN). However I see the usage of long in many places where indicators are used, so I am a bit weary of making a trial & error fix. In any case, I will try to make a new patch that would work on selection as well, although I am not that sure how clean it would be.
 
Andrei
 
-----Original Message-----
From: Engineering [mailto:eng...@as...] 
Sent: Thursday, April 09, 2009 11:24 AM
To: fir...@li...
Subject: [Firebird-odbc-devel] Firebird ODBC: x64 data length compatibility
 
Hello,
 
I was not sure where to report bugs/fixes, so I hope this is the right location. This is the issue that we encountered:
 
   On a x64 Windows 2003 machine, using the ODBC driver we attempted to do a selection from a table containing a DateTime column. MFC CRecordSet uses the data lenth to determine if a field is NULL or not for a date-time, and whenever we had the column as NULL, Firebird ODBC seemed to return the 32-bit value 0xFFFFFFFF (which as a 64-bit value is just a very large number), making our selection invalid (MFC actually complains, because the date/time interpreting is not correct).
 
  From what we could tell, the sequence of events is as follows:
    - MFC Recordset calls ::SQLBindCol with the length parameter as a "LONG_PTR *" (which is a __int64 **)
    - MFC will call ::SQLExtendedFetch, which fills up the length value, however as a 32-bit number (i.e. will be always positive)
 
   I have attached a proposed patch - basically replacing SQLINTEGER with SQLLEN for any index pointers (not sure if this is this the correct term - this is the first time I am messing with this driver). For 32bit this seems to make no difference as the typedefs are the same, however for 64-bit this will change a 32bit value to 64-bit (and would probably need testing). I did test the patch in our environment for date-time columns, however I would appreciate someone more knowledgeable about how the ODBC driver works to take a look. If this can make it into RC2 and/or official release, it would be great.
 
Regards,
Andrei Litvin
 
 
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Firebird-odbc-devel mailing list
Fir...@li...
https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel
  
 


________________________________



 
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
 


________________________________



 
_______________________________________________
Firebird-odbc-devel mailing list
Fir...@li...
https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel
  

Re: [Firebird-odbc-devel] Firebird ODBC: x64 data lengthcompatibility

[Nikolay S. <nik...@re...>]

Andrei, Jorge,

Jorge Andres Brugger wrote:
> Just FYI, Firebird ODBC has a tracker, located at 
> http://tracker.firebirdsql.org/browse/ODBC
>
> Could be a good idea to report the problem and attach the patch there.
>
> Regards
>
> Engineering escribió:
>> Attached is an updated patch that replaces some more indicator pointers with SQLLEN pointers. Behavior seems much better (i.e. selects with and without parameters seem to work on Win64), however I did by no means go through an exhaustive test.
>>
>> Andrei
>>     
The patch seems reasonable to me. I applied it for HEAD and B2_0_0.

-- 
Nikolay Samofatov, MBA
Red Soft Corporation
+1 416 710 6854
+7 495 721 3537

Re: [Firebird-odbc-devel] Firebird ODBC: x64 data lengthcompatibility

[Jorge A. B. <jor...@gm...>]

Just FYI, Firebird ODBC has a tracker, located at 
http://tracker.firebirdsql.org/browse/ODBC

Could be a good idea to report the problem and attach the patch there.

Regards

Engineering escribió:
> Attached is an updated patch that replaces some more indicator pointers with SQLLEN pointers. Behavior seems much better (i.e. selects with and without parameters seem to work on Win64), however I did by no means go through an exhaustive test.
>
> Andrei
>
> -----Original Message-----
> From: Engineering [mailto:eng...@as...] 
> Sent: Thursday, April 09, 2009 2:08 PM
> To: fir...@li...
> Subject: Re: [Firebird-odbc-devel] Firebird ODBC: x64 data lengthcompatibility
>
> I did some further tests .. the attached patch seems to fix the selection but not the prepared statement section (driver crashes with a corrupted heap on statement release). It seems to me that the code assumes that sizeof(long) == 8, which in windows it is not true. On SQLDa.cpp, we have:
> ....
> 	offset = ROUNDUP (offset, sizeof (int));
> 	indicatorsOffset = offset;
> 	offset += sizeof(long) * numberColumns;
> 	buffer = new char [offset];
> 	lengthBufferRows = offset;
> ....
>
> And the part that states sizeof(long) should probably be updated to sizeof(SQLLEN). However I see the usage of long in many places where indicators are used, so I am a bit weary of making a trial & error fix. In any case, I will try to make a new patch that would work on selection as well, although I am not that sure how clean it would be.
>
> Andrei
>
> -----Original Message-----
> From: Engineering [mailto:eng...@as...] 
> Sent: Thursday, April 09, 2009 11:24 AM
> To: fir...@li...
> Subject: [Firebird-odbc-devel] Firebird ODBC: x64 data length compatibility
>
> Hello,
>
> I was not sure where to report bugs/fixes, so I hope this is the right location. This is the issue that we encountered:
>
>    On a x64 Windows 2003 machine, using the ODBC driver we attempted to do a selection from a table containing a DateTime column. MFC CRecordSet uses the data lenth to determine if a field is NULL or not for a date-time, and whenever we had the column as NULL, Firebird ODBC seemed to return the 32-bit value 0xFFFFFFFF (which as a 64-bit value is just a very large number), making our selection invalid (MFC actually complains, because the date/time interpreting is not correct).
>
>   From what we could tell, the sequence of events is as follows:
>     - MFC Recordset calls ::SQLBindCol with the length parameter as a "LONG_PTR *" (which is a __int64 **)
>     - MFC will call ::SQLExtendedFetch, which fills up the length value, however as a 32-bit number (i.e. will be always positive)
>
>    I have attached a proposed patch - basically replacing SQLINTEGER with SQLLEN for any index pointers (not sure if this is this the correct term - this is the first time I am messing with this driver). For 32bit this seems to make no difference as the typedefs are the same, however for 64-bit this will change a 32bit value to 64-bit (and would probably need testing). I did test the patch in our environment for date-time columns, however I would appreciate someone more knowledgeable about how the ODBC driver works to take a look. If this can make it into RC2 and/or official release, it would be great.
>
> Regards,
> Andrei Litvin
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Firebird-odbc-devel mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel
>   
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> ------------------------------------------------------------------------
>
> _______________________________________________
> Firebird-odbc-devel mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel
>   

Re: [Firebird-odbc-devel] SQL Server 2000 DTS

[Ian N. <ia...@co...>]

That was it. There seems to be an issue with getting table lists from 
the driver when using a user other than sysdba.

Do I need to raise this as a bug somewhere?

Regards
Ian

Thomas Steinmaurer wrote:
>> I'm trying to transfer data from SQL Server to firebird using a DTS
>> package. I've done this in the past to firebird 1.5 with no problems.
>>
>> When I try to do the same thing with firebird 2.1 (64 bit) no errors are
>> given but no tables are listed in the transformation destination
>> dropdown. I have tried the latest snapshot version of the driver but no
>> luck so far.
>>
>> I have tried installing the firebird 2.1.2 client on the machine and
>> changed the system dsn to use that instead of the 1.5 one but to no avail.
>>
>> Any ideas anyone?
> 
> Are you using SYSDBA for the connection?
> 
> I've seen various problems (e.g. not listing tables, ...) with 
> third-party tools using the Firebird ODBC driver when you aren't 
> connected as SYSDBA.
> 
> 

Re: [Firebird-odbc-devel] Firebird ODBC: x64 data lengthcompatibility

[Engineering <eng...@as...>]

Attached is an updated patch that replaces some more indicator pointers with SQLLEN pointers. Behavior seems much better (i.e. selects with and without parameters seem to work on Win64), however I did by no means go through an exhaustive test.

Andrei

-----Original Message-----
From: Engineering [mailto:eng...@as...] 
Sent: Thursday, April 09, 2009 2:08 PM
To: fir...@li...
Subject: Re: [Firebird-odbc-devel] Firebird ODBC: x64 data lengthcompatibility

I did some further tests .. the attached patch seems to fix the selection but not the prepared statement section (driver crashes with a corrupted heap on statement release). It seems to me that the code assumes that sizeof(long) == 8, which in windows it is not true. On SQLDa.cpp, we have:
....
	offset = ROUNDUP (offset, sizeof (int));
	indicatorsOffset = offset;
	offset += sizeof(long) * numberColumns;
	buffer = new char [offset];
	lengthBufferRows = offset;
....

And the part that states sizeof(long) should probably be updated to sizeof(SQLLEN). However I see the usage of long in many places where indicators are used, so I am a bit weary of making a trial & error fix. In any case, I will try to make a new patch that would work on selection as well, although I am not that sure how clean it would be.

Andrei

-----Original Message-----
From: Engineering [mailto:eng...@as...] 
Sent: Thursday, April 09, 2009 11:24 AM
To: fir...@li...
Subject: [Firebird-odbc-devel] Firebird ODBC: x64 data length compatibility

Hello,

I was not sure where to report bugs/fixes, so I hope this is the right location. This is the issue that we encountered:

   On a x64 Windows 2003 machine, using the ODBC driver we attempted to do a selection from a table containing a DateTime column. MFC CRecordSet uses the data lenth to determine if a field is NULL or not for a date-time, and whenever we had the column as NULL, Firebird ODBC seemed to return the 32-bit value 0xFFFFFFFF (which as a 64-bit value is just a very large number), making our selection invalid (MFC actually complains, because the date/time interpreting is not correct).

  From what we could tell, the sequence of events is as follows:
    - MFC Recordset calls ::SQLBindCol with the length parameter as a "LONG_PTR *" (which is a __int64 **)
    - MFC will call ::SQLExtendedFetch, which fills up the length value, however as a 32-bit number (i.e. will be always positive)

   I have attached a proposed patch - basically replacing SQLINTEGER with SQLLEN for any index pointers (not sure if this is this the correct term - this is the first time I am messing with this driver). For 32bit this seems to make no difference as the typedefs are the same, however for 64-bit this will change a 32bit value to 64-bit (and would probably need testing). I did test the patch in our environment for date-time columns, however I would appreciate someone more knowledgeable about how the ODBC driver works to take a look. If this can make it into RC2 and/or official release, it would be great.

Regards,
Andrei Litvin


------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Firebird-odbc-devel mailing list
Fir...@li...
https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel

Re: [Firebird-odbc-devel] Firebird ODBC: x64 data length compatibility

[Engineering <eng...@as...>]

I did some further tests .. the attached patch seems to fix the selection but not the prepared statement section (driver crashes with a corrupted heap on statement release). It seems to me that the code assumes that sizeof(long) == 8, which in windows it is not true. On SQLDa.cpp, we have:
....
	offset = ROUNDUP (offset, sizeof (int));
	indicatorsOffset = offset;
	offset += sizeof(long) * numberColumns;
	buffer = new char [offset];
	lengthBufferRows = offset;
....

And the part that states sizeof(long) should probably be updated to sizeof(SQLLEN). However I see the usage of long in many places where indicators are used, so I am a bit weary of making a trial & error fix. In any case, I will try to make a new patch that would work on selection as well, although I am not that sure how clean it would be.

Andrei

-----Original Message-----
From: Engineering [mailto:eng...@as...] 
Sent: Thursday, April 09, 2009 11:24 AM
To: fir...@li...
Subject: [Firebird-odbc-devel] Firebird ODBC: x64 data length compatibility

Hello,

I was not sure where to report bugs/fixes, so I hope this is the right location. This is the issue that we encountered:

   On a x64 Windows 2003 machine, using the ODBC driver we attempted to do a selection from a table containing a DateTime column. MFC CRecordSet uses the data lenth to determine if a field is NULL or not for a date-time, and whenever we had the column as NULL, Firebird ODBC seemed to return the 32-bit value 0xFFFFFFFF (which as a 64-bit value is just a very large number), making our selection invalid (MFC actually complains, because the date/time interpreting is not correct).

  From what we could tell, the sequence of events is as follows:
    - MFC Recordset calls ::SQLBindCol with the length parameter as a "LONG_PTR *" (which is a __int64 **)
    - MFC will call ::SQLExtendedFetch, which fills up the length value, however as a 32-bit number (i.e. will be always positive)

   I have attached a proposed patch - basically replacing SQLINTEGER with SQLLEN for any index pointers (not sure if this is this the correct term - this is the first time I am messing with this driver). For 32bit this seems to make no difference as the typedefs are the same, however for 64-bit this will change a 32bit value to 64-bit (and would probably need testing). I did test the patch in our environment for date-time columns, however I would appreciate someone more knowledgeable about how the ODBC driver works to take a look. If this can make it into RC2 and/or official release, it would be great.

Regards,
Andrei Litvin

[Firebird-odbc-devel] Firebird ODBC: x64 data length compatibility

[Engineering <eng...@as...>]

Hello,

I was not sure where to report bugs/fixes, so I hope this is the right location. This is the issue that we encountered:

   On a x64 Windows 2003 machine, using the ODBC driver we attempted to do a selection from a table containing a DateTime column. MFC CRecordSet uses the data lenth to determine if a field is NULL or not for a date-time, and whenever we had the column as NULL, Firebird ODBC seemed to return the 32-bit value 0xFFFFFFFF (which as a 64-bit value is just a very large number), making our selection invalid (MFC actually complains, because the date/time interpreting is not correct).

  From what we could tell, the sequence of events is as follows:
    - MFC Recordset calls ::SQLBindCol with the length parameter as a "LONG_PTR *" (which is a __int64 **)
    - MFC will call ::SQLExtendedFetch, which fills up the length value, however as a 32-bit number (i.e. will be always positive)

   I have attached a proposed patch - basically replacing SQLINTEGER with SQLLEN for any index pointers (not sure if this is this the correct term - this is the first time I am messing with this driver). For 32bit this seems to make no difference as the typedefs are the same, however for 64-bit this will change a 32bit value to 64-bit (and would probably need testing). I did test the patch in our environment for date-time columns, however I would appreciate someone more knowledgeable about how the ODBC driver works to take a look. If this can make it into RC2 and/or official release, it would be great.

Regards,
Andrei Litvin

Re: [Firebird-odbc-devel] Odbc driver pre-RC2

[Alan B. <_@_._>]

Alexander,

Just one minor issue, re installing from a batch file to do a silent install

Using build 144 the following command line switches work as expected and 
only does a deployment install :-

  Firebird_ODBC_2.0.0.144_Win32.exe  /SP- /VERYSILENT 
/COMPONENTS="DeploymentComponent"

Using build 149 using the same command line switches :-

  Firebird_ODBC_2.0.0_Win32.exe  /SP- /VERYSILENT 
/COMPONENTS="DeploymentComponent"

seems to ignore the DeploymentComponent option and does a developer install 
regardless

Regard

Alan 

Re: [Firebird-odbc-devel] SQL Server 2000 DTS

[Thomas S. <ts...@ib...>]

> I'm trying to transfer data from SQL Server to firebird using a DTS
> package. I've done this in the past to firebird 1.5 with no problems.
> 
> When I try to do the same thing with firebird 2.1 (64 bit) no errors are
> given but no tables are listed in the transformation destination
> dropdown. I have tried the latest snapshot version of the driver but no
> luck so far.
> 
> I have tried installing the firebird 2.1.2 client on the machine and
> changed the system dsn to use that instead of the 1.5 one but to no avail.
> 
> Any ideas anyone?

Are you using SYSDBA for the connection?

I've seen various problems (e.g. not listing tables, ...) with 
third-party tools using the Firebird ODBC driver when you aren't 
connected as SYSDBA.


-- 
Best Regards,
Thomas Steinmaurer
LogManager Series - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database, MS SQL Server and
NexusDB V2
Upscene Productions
http://www.upscene.com
My blog:
http://blog.upscene.com/thomas/

Re: [Firebird-odbc-devel] SQL Server 2000 DTS

[Helen B. <he...@ii...>]

At 08:40 PM 2/04/2009, you wrote:
>Hi folks,
>I'm trying to transfer data from SQL Server to firebird using a DTS
>package. I've done this in the past to firebird 1.5 with no problems.
>
>When I try to do the same thing with firebird 2.1 (64 bit) no errors are
>given but no tables are listed in the transformation destination
>dropdown. I have tried the latest snapshot version of the driver but no
>luck so far.
>
>I have tried installing the firebird 2.1.2 client on the machine and
>changed the system dsn to use that instead of the 1.5 one but to no avail.
>
>Any ideas anyone?

1.  64-bit client or 32-bit?
2.  Did you install the msvc8 runtime assembly on the client as well?  You'd need the 32-bit one.

Helen

Re: [Firebird-odbc-devel] SQL Server 2000 DTS

[Alexandre B. S. <ib...@th...>]

Ian,

Ian Newby wrote:
> Hi folks,
> I'm trying to transfer data from SQL Server to firebird using a DTS
> package. I've done this in the past to firebird 1.5 with no problems.
>
> When I try to do the same thing with firebird 2.1 (64 bit) no errors are
> given but no tables are listed in the transformation destination
> dropdown. I have tried the latest snapshot version of the driver but no
> luck so far.
>
> I have tried installing the firebird 2.1.2 client on the machine and
> changed the system dsn to use that instead of the 1.5 one but to no avail.
>
> Any ideas anyone?
>
> Regards
>
> Ian
>   

Not an answer to your question...

I don't know what kind of transformation do you need, but did you give a 
try to IBDataPump ? I had pumped data with it a lot of times with sucess.

see you !

-- 
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br



__________ Information from ESET NOD32 Antivirus, version of virus signature database 3986 (20090403) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[Firebird-odbc-devel] SQL Server 2000 DTS

[Ian N. <ia...@co...>]

Hi folks,
I'm trying to transfer data from SQL Server to firebird using a DTS
package. I've done this in the past to firebird 1.5 with no problems.

When I try to do the same thing with firebird 2.1 (64 bit) no errors are
given but no tables are listed in the transformation destination
dropdown. I have tried the latest snapshot version of the driver but no
luck so far.

I have tried installing the firebird 2.1.2 client on the machine and
changed the system dsn to use that instead of the 1.5 one but to no avail.

Any ideas anyone?

Regards

Ian

[Firebird-odbc-devel] SQL Server 2000 DTS

[Ian N. <ia...@co...>]

Hi folks,
I'm trying to transfer data from SQL Server to firebird using a DTS 
package. I've done this in the past to firebird 1.5 with no problems.

When I try to do the same thing with firebird 2.1 (64 bit) no errors are 
given but no tables are listed in the transformation destination 
dropdown. I have tried the latest snapshot version of the driver but no 
luck so far.

I have tried installing the firebird 2.1.2 client on the machine and 
changed the system dsn to use that instead of the 1.5 one but to no avail.

Any ideas anyone?

Regards

Ian

Re: [Firebird-odbc-devel] Odbc driver pre-RC2

[Alexander P. <ale...@gm...>]

Jorge Andrés Brugger wrote:
> I´m not talking about the package, but the DLL (OdbcFb.dll):
>
> Build 147: 620 KB
> Build 148: 620 KB (32bit build)
> Build 149: 1.2MB
>
> Why the DLL is so big now?
>   
After enabling Linker->Debugging->Generate Debug Info the linker added 
some information into the library.
After some modifications I have made the size 952 KB (OdbcFb.pdb - 
4400KB in this case). It should not affect performance.

Regards,
Alexander

Re: [Firebird-odbc-devel] Odbc driver pre-RC2

[bill l. <cbi...@gm...>]

On Wed, 18 Mar 2009, Jorge Andrés Brugger wrote:
> I´m not talking about the package, but the DLL (OdbcFb.dll):
> 
> Build 147: 620 KB
> Build 148: 620 KB (32bit build)
> Build 149: 1.2MB
> 
> Why the DLL is so big now?

I no longer use odbcfb.dll but I guess the dll was just not stripped.
Does it shrink after 
strip odbcfb.dll 

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩223 沈佺期  古意呈補闕喬知之
    盧家少婦鬱金香  海燕雙棲玳瑁梁  九月寒砧催木葉  十年征戍憶遼陽
    白狼河北音書斷  丹鳳城南秋夜長  誰為含愁獨不見  更教明月照流黃

Re: [Firebird-odbc-devel] Odbc driver pre-RC2

[Jorge A. B. <li...@da...>]

I´m not talking about the package, but the DLL (OdbcFb.dll):

Build 147: 620 KB
Build 148: 620 KB (32bit build)
Build 149: 1.2MB

Why the DLL is so big now?

Alexander Potapchenko escribió:
> Jorge Andrés Brugger wrote:
>   
>> Why the size is almost the double than 147 build and 1/3 bigger than 148?
>>
>>   
>>     
> The packages includes a debug information (OdbcFb.pdb) and standard 
> library (OdbcFb.lib).
>
> Regards,
> Alexander
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Firebird-odbc-devel mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel
>
>
>   

Re: [Firebird-odbc-devel] Odbc driver pre-RC2

[Alexander P. <ale...@gm...>]

Jorge Andrés Brugger wrote:
> Why the size is almost the double than 147 build and 1/3 bigger than 148?
>
>   
The packages includes a debug information (OdbcFb.pdb) and standard 
library (OdbcFb.lib).

Regards,
Alexander

Re: [Firebird-odbc-devel] Odbc driver pre-RC2

[Jorge A. B. <li...@da...>]

Why the size is almost the double than 147 build and 1/3 bigger than 148?

GMail escribió:
> Hi all,
>
> I have built the ODBC driver snapshots (build 149 Pre-RC2). Look the
> changes in the changelog.
> You can find it here -
> http://www.firebirdsql.org/downloads/snapshot_builds/odbc/
>
> Regards,
> Alexander Potapchenko
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Firebird-odbc-devel mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel
>
>
>   

Re: [Firebird-odbc-devel] Odbc driver pre-RC2

[Jorge A. B. <li...@da...>]

Thanks Alexander!

GMail escribió:
> Hi all,
>
> I have built the ODBC driver snapshots (build 149 Pre-RC2). Look the
> changes in the changelog.
> You can find it here -
> http://www.firebirdsql.org/downloads/snapshot_builds/odbc/
>
> Regards,
> Alexander Potapchenko
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Firebird-odbc-devel mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel
>
>
>   

[Firebird-odbc-devel] Odbc driver pre-RC2

[GMail <ale...@gm...>]

Hi all,

I have built the ODBC driver snapshots (build 149 Pre-RC2). Look the
changes in the changelog.
You can find it here -
http://www.firebirdsql.org/downloads/snapshot_builds/odbc/

Regards,
Alexander Potapchenko

Re: [Firebird-odbc-devel] Driver issues

[Martijn T. <m.t...@up...>]

Hello Alexander,

>> It returns from SQLExecute instantly now, so that's good.
>>
>> But when going through all rows, it still takes a lot of memory, as
>> if all blobs are instantiated in memory. What could cause this?
>>
>>   
> It seems that the client application caches the data. If the cursor type 
> is FORWARD ONLY the driver should not caches the prior records.

I've changed the call so that the components use an ODBC cursor
type of FORWARD ONLY, yet, I can still see the memory use
increase when working with blobs and cycling the resultset.

I've forwarded this issue to the component creators too, perhaps 
you can check as well?

With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!

Database questions? Check the forum:
http://www.databasedevelopmentforum.com

[Firebird-odbc-devel] Connecting InterBase database (*.GDB) in MS Access 2007

[Nicholas L. <jiu...@si...>]

Hi,

Wondering is there any way to access/extract interBase database data in
MS Access 2007.  Please help.

 

 

nicholas lee

|  mis department  |  skype:  Sixny-Jiun Hoow  |  jiu...@si...
<mailto:jiu...@si...>   |  ext 240  | 

 

Re: [Firebird-odbc-devel] Driver issues

[Alexander P. <ale...@re...>]

Martijn Tonies wrote:
> It returns from SQLExecute instantly now, so that's good.
>
> But when going through all rows, it still takes a lot of memory, as
> if all blobs are instantiated in memory. What could cause this?
>
>   
It seems that the client application caches the data. If the cursor type 
is FORWARD ONLY the driver should not caches the prior records.

Regards,
Alexander

Re: [Firebird-odbc-devel] Driver issues

[Martijn T. <m.t...@up...>]

Hello Alexander,

>> I've tried a different componentset and it browses data just
>> fine in Delphi.
>>
>> However, I ran into a new problem --
>>
>> I have this table with BLOBs, I put down an odbc query
>> component in Delphi and set "UniDirectional" to True.
>>
>> When I want to activate the query component, it calls
>> SQLExecute and then doesn't return for quite a while.
>> Meanwhile, the memory usage of the application goes
>> -way up- ... and it ends with an Access Violation error.
>>
>> Is the driver fetching all rows despite the component
>> not doing that?
>>
>>
>>
> Hello Martijn!
> What components do you use?

The ones from SoftVector.

> I think you need the Cursor type  = ForwardOnly (else the driver
> fetching all rows) .

It seems the components always used a static cursor. I've modified
the components to use a ForwardOnly cursor:

  if FUniDirectional
  then CheckError(SQLSetStmtAttr(FStmtHandle, SQL_ATTR_CURSOR_TYPE, 
Pointer(SQL_CURSOR_FORWARD_ONLY), SQL_IS_UINTEGER))
  // set static cursor to avoid problems with blobs
  else CheckError(SQLSetStmtAttr(FStmtHandle, SQL_ATTR_CURSOR_TYPE, 
Pointer(SQL_CURSOR_STATIC), SQL_IS_UINTEGER));


It returns from SQLExecute instantly now, so that's good.

But when going through all rows, it still takes a lot of memory, as
if all blobs are instantiated in memory. What could cause this?

With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!

Database questions? Check the forum:
http://www.databasedevelopmentforum.com