Hello Alex...
I'm afraid it still doesn't work. I have set the pgConnection ProtocolVersion to pv20 both at design time and also in the BeforeConnect event handler and I get exactly the same result with the Postgres 7 database.
Please advise when you have a fix for this problem.
Thanks,
Alex.
Search found 18 matches
- Tue 03 Apr 2012 20:31
- Forum: PostgreSQL Data Access Components
- Topic: Type "e" does not exist.
- Replies: 10
- Views: 4354
- Tue 03 Apr 2012 12:35
- Forum: PostgreSQL Data Access Components
- Topic: Type "e" does not exist.
- Replies: 10
- Views: 4354
- Mon 02 Apr 2012 23:27
- Forum: PostgreSQL Data Access Components
- Topic: Type "e" does not exist.
- Replies: 10
- Views: 4354
For completeness, this is the definition of the tables referred to in the parameterised query which fails under Postgres 7.4.19:
Because the query fails before it's even executed, I have confirmed that the actual data is irrelevant - the problem definitely occurs with the parameters given in my last post with empty tables as defined above.
Also, the connection object is defined as follows:
Could someone form Devart please reply to confirm that this problem is being investigated?
Thanks,
Alex.
Code: Select all
CREATE TABLE users
(
user_id character varying(8) NOT NULL,
user_name character varying(40),
user_manager_id character varying(8),
passwd character varying(50),
passwd_expiry_date date,
db_passwd character varying(50),
user_status character(1),
email character varying(64),
user_location character varying(40),
user_phone character varying(32),
user_contact_info character varying(100),
default_printer_key smallint,
hint_level smallint DEFAULT 1,
signon_cnt smallint DEFAULT 0,
failed_signon_cnt smallint DEFAULT 0,
last_signon_date timestamp(0) with time zone,
signon_tag integer DEFAULT 0,
shell_opts character varying(32),
create_date timestamp with time zone,
create_user_id character varying(8),
last_upd_date timestamp with time zone,
last_upd_user_id character varying(8),
location_list character varying(64),
location_key integer,
CONSTRAINT users_pkey PRIMARY KEY (user_id),
CONSTRAINT "$1" CHECK (user_status = 'I'::bpchar OR user_status = 'A'::bpchar OR user_status = 'T'::bpchar OR user_status = 'L'::bpchar)
)
WITHOUT OIDS;
CREATE TABLE user_auths
(
user_id character varying(8) NOT NULL,
soc_code character varying(8) NOT NULL,
access_option character varying(20),
user_status character(1),
db_name character varying(32),
email character varying(64),
default_printer_key smallint,
create_date timestamp with time zone,
create_user_id character varying(8),
last_upd_date timestamp with time zone,
last_upd_user_id character varying(8),
location_key integer,
CONSTRAINT user_auths_pkey PRIMARY KEY (user_id, soc_code),
CONSTRAINT ua_db_name_fk FOREIGN KEY (soc_code, db_name)
REFERENCES dbs (soc_code, db_name) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT "$1" CHECK (user_status = 'I'::bpchar OR user_status = 'A'::bpchar OR user_status = 'T'::bpchar)
)
WITHOUT OIDS;
Also, the connection object is defined as follows:
Code: Select all
object AdminPgConnection1: TPgConnection
Username = 'user'
Password = 'password'
Server = '192.168.0.100'
LoginPrompt = False
AfterConnect = PgConnection1AfterConnect
BeforeConnect = PgConnection1BeforeConnect
AfterDisconnect = PgConnection1AfterDisconnect
Database = 'admin_db'
Options.ApplicationName = 'pgDACTest'
ConnectionTimeout = 1
Left = 584
Top = 56
end
Thanks,
Alex.
- Fri 30 Mar 2012 00:41
- Forum: PostgreSQL Data Access Components
- Topic: Type "e" does not exist.
- Replies: 10
- Views: 4354
We are also having this issue with pgDAC version 3.1.5 in Delphi 7. It appears to be related to parameters, as a non-parameterised version of the query works without any problems. Note that the problem occurs with PostgreSQL version 7.4.19 but does not happen with PostgreSQL version 9.0.5. Both databases are LATIN9 encoding.
This is the error message I get when the query is opened:
The problem does not occur with all parameterised queries, but it occurs consistently with the following TpgQuery object:
This is the relevant section from a log obtained via a TPgSQLMonitor component:
This is a serious problem for us as we attempt to migrate from dbExpress to pgDAC, so I hope the above information will help you isolate and fix the problem quickly.
Regards,
Alex.
This is the error message I get when the query is opened:
Code: Select all
---------------------------
Debugger Exception Notification
---------------------------
Project MyQ.exe raised exception class EOleException with message 'type "e" does not exist'. Process stopped. Use Step or Run to continue.
---------------------------
OK Help
---------------------------
Code: Select all
object AuthenticationABRIpgQuery1: TPgQuery
Connection = AdminPgConnection1
SQL.Strings = (
'select u.*, ua.soc_code, ua.access_option '
'from users u '
'left join user_auths ua on u.user_id = ua.user_id '
'where u.user_status = ''A'' '
'and u.user_id = :UserID '
'and passwd = :Password;')
ReadOnly = True
Options.ExtendedFieldsInfo = False
Options.UnknownAsString = True
Options.UnpreparedExecute = True
Left = 184
Top = 304
ParamData =
end
Code: Select all
11:20:38.191 Start:
11:20:38.237 select u.*, ua.soc_code, ua.access_option
from users u
left join user_auths ua on u.user_id = ua.user_id
where u.user_status = 'A'
and u.user_id = :UserID
and passwd = :Password;
:UserID(String[2],IN)='aj'
:Password(String[16],IN)='vG85YqZ9zSziXw=='
11:20:38.316 Error: type "e" does not exist
11:20:41.784 Commit:
Regards,
Alex.
- Tue 22 Nov 2011 04:49
- Forum: dbExpress driver for PostgreSQL
- Topic: Daylight savings bug with timestamptz field
- Replies: 11
- Views: 4112
Dear Alex,
I have received no response to my e-mails to you on this subject, so I am posting this in the forum thread. We have had previous support issues addressed using the number quoted, so I am not sure why to you believe it to be for MySQL rather than PostgreSQL.
Please refer to original message below:
> From: Devart Sales
> Date: 26 November 2010 20:28:12 AEDT
> To: cdecrespigny(at)gmail.com
> Subject: dbExpress driver for PostgreSQL
>
>
> Thank you for the registration of dbExpress driver for PostgreSQL Standard
> with source code single license.
>
> Your developer license number is CRDBM-00383..
> Please use it when contact us.
>
> You can download the full version of dbExpress driver for Windows
> and source code as protected archive (Password: **********) at
> http://secure.devart.com/
>
> User: dbxpgsql130src
> Psw: **********
>
> Note: you have one year DbxPgSQL subscription starting from this date.
>
> Please write to [email protected] if you have any
> questions or problems with our product.
> Also you can post your comments to DbxPgSQL discussion
> forum that is available from http://devart.com/forums
>
> Devart Sales Team
> [email protected]
I trust this matter can be resolved quickly.
Regards,
Alex.
I have received no response to my e-mails to you on this subject, so I am posting this in the forum thread. We have had previous support issues addressed using the number quoted, so I am not sure why to you believe it to be for MySQL rather than PostgreSQL.
Please refer to original message below:
> From: Devart Sales
> Date: 26 November 2010 20:28:12 AEDT
> To: cdecrespigny(at)gmail.com
> Subject: dbExpress driver for PostgreSQL
>
>
> Thank you for the registration of dbExpress driver for PostgreSQL Standard
> with source code single license.
>
> Your developer license number is CRDBM-00383..
> Please use it when contact us.
>
> You can download the full version of dbExpress driver for Windows
> and source code as protected archive (Password: **********) at
> http://secure.devart.com/
>
> User: dbxpgsql130src
> Psw: **********
>
> Note: you have one year DbxPgSQL subscription starting from this date.
>
> Please write to [email protected] if you have any
> questions or problems with our product.
> Also you can post your comments to DbxPgSQL discussion
> forum that is available from http://devart.com/forums
>
> Devart Sales Team
> [email protected]
I trust this matter can be resolved quickly.
Regards,
Alex.
- Tue 25 Oct 2011 23:58
- Forum: dbExpress driver for PostgreSQL
- Topic: Daylight savings bug with timestamptz field
- Replies: 11
- Views: 4112
- Mon 24 Oct 2011 22:10
- Forum: dbExpress driver for PostgreSQL
- Topic: Daylight savings bug with timestamptz field
- Replies: 11
- Views: 4112
- Fri 14 Oct 2011 12:30
- Forum: dbExpress driver for PostgreSQL
- Topic: Daylight savings bug with timestamptz field
- Replies: 11
- Views: 4112
- Tue 11 Oct 2011 18:49
- Forum: dbExpress driver for PostgreSQL
- Topic: Daylight savings bug with timestamptz field
- Replies: 11
- Views: 4112
This query will return the current server time as a timestamptz field. It displays the correct daylight savings time in pgAdmin or any Delphi application not using Devart, but displays a time an hour earlier when using Devart.AlexP wrote:and also specify the result of execution of the following query:
select now()
I suggested "now()" as a test case because it is independent of any schema. We often retrieve the value of fields populated using the "now()" function and, despite containing the correct value, these fields display the incorrect time when read via Devart.
- Tue 11 Oct 2011 12:32
- Forum: dbExpress driver for PostgreSQL
- Topic: Daylight savings bug with timestamptz field
- Replies: 11
- Views: 4112
The postgresql.conf leaves the timezone parameter unspecified, so postgres defaults to the system timezone, which is set to Australia/Sydney. The system clock is set to UTC.
Note that the time displayed is correct when using the ZeosLib data access components and also when using the pgExpress dbExpress driver. The time displays correctly everywhere except applications using the Devart dbExpress driver.
Note that the time displayed is correct when using the ZeosLib data access components and also when using the pgExpress dbExpress driver. The time displays correctly everywhere except applications using the Devart dbExpress driver.
- Tue 11 Oct 2011 05:54
- Forum: dbExpress driver for PostgreSQL
- Topic: Daylight savings bug with timestamptz field
- Replies: 11
- Views: 4112
Daylight savings bug with timestamptz field
G'day all...
Since Australia went onto daylight savings time, We have a problem where the values of timestamptz fields are displaying in non-daylight-savings time instead of the correct daylight-savings time (i.e. one hour earlier). The correct time is displayed in pgExpress.
The problem is easily replicated by using the SQL statement "select now();", and it will display the incorrect (non-daylight-savings) time as the value of the returned field. The date/time and timezone settings are correct and up-to-date on both the server and the client.
So far, we have the problem with Postgres version 7, and the problem occurs in the Devart dbExpress drivers for PostgreSQL versions 1.3 and 2.0.
This is now an urgent problem for us as it is affecting live systems. Is there a fix or work-around available immediately? Any help would be much appreciated.
Thanks,
Alex.
Since Australia went onto daylight savings time, We have a problem where the values of timestamptz fields are displaying in non-daylight-savings time instead of the correct daylight-savings time (i.e. one hour earlier). The correct time is displayed in pgExpress.
The problem is easily replicated by using the SQL statement "select now();", and it will display the incorrect (non-daylight-savings) time as the value of the returned field. The date/time and timezone settings are correct and up-to-date on both the server and the client.
So far, we have the problem with Postgres version 7, and the problem occurs in the Devart dbExpress drivers for PostgreSQL versions 1.3 and 2.0.
This is now an urgent problem for us as it is affecting live systems. Is there a fix or work-around available immediately? Any help would be much appreciated.
Thanks,
Alex.
- Wed 31 Aug 2011 22:19
- Forum: dbExpress driver for PostgreSQL
- Topic: ExecSQL() Error: "No value for parameter '[^[:digit:]]*'"
- Replies: 1
- Views: 3559
ExecSQL() Error: "No value for parameter '[^[:digit:]]*'"
G'day all...
We are converting a working application from the ZeosLib data access components to pgExpress with Devart drivers.
We have a problem with the Devart pgExpress drivers throwing an error on a call to TSQLQUery.ExecSQL(). This query evaluates perfectly in pgAdmin, and previously when using the ZeosLib data access components. All we are doing is setting the SQLQUery.SQL.Text property and calling ExecSQL(), and there are no event handlers or parameters set up on the SQLQuery object.
The error is:
The query text is as follows:
I am continuing to investigate this and I am attempting to create a simple test case, but can anyone shed any light on where the error is coming from?
I should add that this is occuring in Delphi 7. The reason for the change to Devart is that we are preparing to migrate the application to a more current version of Delphi.
Thanks,
Alex.
We are converting a working application from the ZeosLib data access components to pgExpress with Devart drivers.
We have a problem with the Devart pgExpress drivers throwing an error on a call to TSQLQUery.ExecSQL(). This query evaluates perfectly in pgAdmin, and previously when using the ZeosLib data access components. All we are doing is setting the SQLQUery.SQL.Text property and calling ExecSQL(), and there are no event handlers or parameters set up on the SQLQuery object.
The error is:
- No value for parameter '[^[:digit:]]*'
The query text is as follows:
Code: Select all
set search_path = aull, breedplan, public;
set session authorization sk;
/* if the header record doesn't already exist for this calving year, create it */
insert into membership_years (soc_code, members_key, membership_year,
membership_rec_type, membership_type, membership_status,
date_assessed, membership_key)
select zt.soc_code, zt.members_key, 2011, 2,
cast('6' || cast('4' as varchar) as integer), 1,
local_timestamp_f('AULL'), cast(next_seq_no_f('AULL', 'MY', 'MEMBERSHIP_KEY') as integer) as membership_key
from ztmp.ztmp_251077_memberkeys zt
where zt.members_key not in
(select ztt.members_key from ztmp.ztmp_251077_memberkeys ztt
join membership_years my using (soc_code, members_key)
where ztt.soc_code = 'AULL'
and my.membership_rec_type = 2
and my.membership_type = cast('6' || cast('4' as varchar) as integer)
and my.membership_year = 2011);
/*===============================================================*/
/* save stuff away for the report */
/* note: this needs fixing because you could have multiple member link rows and this table should only
ever return ONE row */
create table ztmp.ztmp_251077_rpthdgs as
select me.soc_code,
me.member_ident,
me.members_key,
mp.member_ident as primary_herd,
mp.memb_name as primary_name,
me.stud_letters,
me.pref_language,
me.stud_prefix,
me.soc_me_cb_1 as invent_status,
me.soc_me_ck_4_flag as full_invent,
(select alt_member_ident from member_cross_refs where soc_code='AULL' and alt_type=3 and members_key=me.members_key limit 1) as nlis_pic,
me.memb_name,
me.address_1,
me.address_2,
me.address_3,
param_to_description_f(me.soc_code, 'STATE', me.state) as me_state,
me.postcode,
me.phone_priv,
me.phone_fax,
cast('2011' as varchar(4)) as calv_yr ,
cast(param_to_description_f(me.soc_code, 'INVENTORY_SEASON', '4') as varchar(16)) as calv_seas,
cm.company_name,
cm.address_1 as cm_address_1, cm.address_2 as cm_address_2,
cm.address_3 as cm_address_3, cm.postcode as cm_postcode,
param_to_description_f(cm.soc_code, 'STATE', cm.state) as cm_state,
param_to_description_f(cm.soc_code, 'COUNTRY', cm.country) as cm_country,
cm.phone_bus as cm_phone_bus,
cm.phone_bus_2 as cm_phone_bus_2,
cm.phone_fax as cm_phone_fax,
cm.email as cm_email ,
my.membership_key as invent_year_key,
case when 'N' = 'Y' then 'Y' else 'N' end as do_update_counts,
to_char(local_timestamp_f(me.soc_code) ,'FMMonth dd, yyyy') as issue_date,
case when 'AULL' = 'CANG' then me.soc_me_cb_2 else cast(null as int2) end as anim_rpt_sort_order
from ztmp.ztmp_251077_memberkeys zt
join members me on me.soc_code = zt.soc_code and me.members_key = zt.members_key
join companies cm on cm.soc_code = zt.soc_code
left join member_links ml on ml.soc_code = zt.soc_code and ml.secondary_members_key = me.members_key and ml.member_link_type = 2
and member_link_exists_f(ml.soc_code,ml.primary_members_key,ml.secondary_members_key,2,'20110831')
left join members mp on mp.soc_code = zt.soc_code and ml.primary_members_key = mp.members_key
join membership_years my on my.soc_code = zt.soc_code
and my.members_key = me.members_key
and my.membership_year = '2011'
and my.membership_rec_type = 2
and my.membership_type = cast('6' || cast('4' as varchar) as integer)
where zt.soc_code = 'AULL' ;
/*===============================================================*/
/* if we are re-calculating figures, delete the old ones from membership_inventory */
delete from membership_inventory
where soc_code = 'AULL'
and membership_key in
(select invent_year_key from
ztmp.ztmp_251077_rpthdgs hdg
where hdg.do_update_counts = 'Y');
/*===============================================================*/
/* if you are recalculating figures, gather up all currently owned animals for the herds */
/* if not updating, pass the empty string into members_inventory_load_f so that an empty keys table gets created */
select members_inventory_load_f(case when
exists(select 1
from ztmp.ztmp_251077_rpthdgs hdg
where hdg.do_update_counts = 'Y' group by 1) then 'ztmp_251077_memberkeys' else '' end, 'ztmp_251077_animalkeys', cast('20110831' as date))
;
/*===============================================================*/
/* to get in the inventory you must be
1. Female
2. Active
4. of correct age ie. older than the minimum date of birth entered by the user, and younger than that date - 16 years
*/
insert into membership_inventory
( soc_code,membership_key,animals_key, rego_status)
select mi.soc_code, hdg.invent_year_key, an.animals_key, an.rego_status
from ztmp.ztmp_251077_animalkeys mi
join animals an on an.soc_code = mi.soc_code and an.animals_key = mi.animals_key
join ztmp.ztmp_251077_rpthdgs hdg on hdg.soc_code = mi.soc_code and hdg.members_key = mi.members_key
where an.sex = 1
and an.anim_type 5
and mi.anim_status = 1
and held_status is null
and ((an.date_of_birth <= 20110831 and an.date_of_birth is not null)
or (an.calving_year <= extract(year from cast('20110831' as date)) and an.date_of_birth is null))
and (get_global_f(an.soc_code, 'inventory_registered_only') is distinct from 'true' or an.rego_status = 11)
and hdg.do_update_counts = 'Y'
order by hdg.member_ident,
an_format_ilr1_ident_f(an.soc_code, 'out', null, an.anim_ident),
anim_type,
param_to_abbrev_f(an.soc_code,'SEX',an.sex) desc,
coalesce(an.calving_year,extract('year' from an.date_of_birth)),
cast (nullif(substring(an.tattoo from '^(?:[^[:digit:]]*)([[:digit:]]*)'),'') as integer),
substring(an.tattoo from '^[^ ]*' );
/* analyze the report headings so it can join it properly */
select sys_analyse_table_f('ztmp.ztmp_251077_rpthdgs');
/*===============================================================*/
/* make this the rpt bit then */
create table ztmp.ztmp_251077_inventanims as
select hdg.members_key,
hdg.member_ident,
hdg.primary_herd,
hdg.primary_name,
hdg.stud_letters,
hdg.memb_name,
hdg.address_1,
hdg.address_2,
hdg.address_3,
hdg.me_state,
hdg.postcode,
hdg.phone_priv,
hdg.phone_fax,
hdg.calv_yr ,
hdg.calv_seas,
hdg.company_name,
hdg.cm_address_1,
hdg.cm_address_2,
hdg.cm_address_3,
hdg.cm_postcode,
hdg.cm_state,
hdg.cm_country,
hdg.cm_phone_bus,
hdg.cm_phone_bus_2,
hdg.cm_phone_fax,
hdg.cm_email ,
hdg.issue_date,
hdg.pref_language,
hdg.anim_rpt_sort_order,
hdg.stud_prefix,
hdg.nlis_pic,
hdg.invent_status,
cast(case when full_invent then '23.10' else '9.90' end as varchar(5)) as invent_fee,
cast(case when full_invent then '20.90' else '8.80' end as varchar(5)) as invent_fee_disc,
mi.*,
an_format_ident_f(an.soc_code,an.animals_key) as anim_ident,
an.tattoo,
an.herd_id,
an.anim_name,
an.calving_year,
an.inventory_season,
substr(get_global_f(an.soc_code, 'year_letters')
/*,cast(extract(year from an.date_of_birth) as integer) */
, cast('2011' as integer)
-get_global_int_f(an.soc_code, 'year_letter_base')+1,1) as anim_year_letter,
param_to_abbrev_f(an.soc_code,'SEX',an.sex) as sex_abbr,
param_to_abbrev_f(an.soc_code,'REGO_STATUS',an.rego_status) as reg_abbr,
an_format_ilr1_ident_f(an.soc_code, 'out', null, an.anim_ident) as sort_anim_ident,
cast(2011 as int) as inventory_year,
cast(param_to_description_f(an.soc_code, 'SEASON', '4') as varchar(16)) as invent_season_desc,
cast(sys_year_code_f('AULL', 2011) as varchar(1))as current_year_code,
cast(2011 as integer) as current_year,
an.anim_type as reg_order,
sire_tattoo,
sire_ident,
sire_ai,
sire_date
from ztmp.ztmp_251077_rpthdgs hdg
join membership_inventory mi on mi.soc_code = hdg.soc_code and mi.membership_key = hdg.invent_year_key
join animals an on an.soc_code = mi.soc_code and an.animals_key = mi.animals_key
left join (select sd.dam_key as animals_key, an1.tattoo as sire_tattoo, an1.anim_ident as sire_ident, case when sd.service_type = 2 then 'Y' else null end as sire_ai, sd.from_service_date as sire_date
from service_details sd
join animals an1 on an1.soc_code = sd.soc_code and an1.animals_key = sd.sire_key
join ztmp.ztmp_251077_rpthdgs hdg on hdg.soc_code = an1.soc_code
join membership_inventory mi on mi.soc_code = hdg.soc_code and mi.membership_key = hdg.invent_year_key
where sd.dam_key = mi.animals_key
and sd.from_service_date = (select from_service_date from service_details sd1
where sd1.soc_code= hdg.soc_code and sd1.dam_key = sd.dam_key
and coalesce(sd1.service_status,0) = 0
and sd1.from_service_date between cast(cast(to_number(hdg.calv_yr,'9999') - 1 as char(4)) || '-01-01' as date)
and cast(cast(to_number(hdg.calv_yr,'9999') - 1 as char(4)) || '-12-31' as date)
order by sd1.from_service_date asc limit 1))
sd on sd.animals_key = mi.animals_key ;
/* and t3941.adls_flag = 'N' and t3941.forms_flag = 'Y' */
I should add that this is occuring in Delphi 7. The reason for the change to Devart is that we are preparing to migrate the application to a more current version of Delphi.
Thanks,
Alex.
- Sun 14 Aug 2011 23:28
- Forum: dbExpress driver for PostgreSQL
- Topic: Support for XE2 / Firemonkey
- Replies: 3
- Views: 3443
Support for XE2 / Firemonkey
Hello...
Will Devart have the PostgreSQL dbExpress drivers ready for the release of Delphi XE2?
Also, will the drivers be available for OSX and other platforms supported by Firemonkey? If not, when do you think they might be available?
Thanks,
Alex
Will Devart have the PostgreSQL dbExpress drivers ready for the release of Delphi XE2?
Also, will the drivers be available for OSX and other platforms supported by Firemonkey? If not, when do you think they might be available?
Thanks,
Alex
- Sun 09 Jan 2011 23:55
- Forum: dbExpress driver for PostgreSQL
- Topic: dclcrdbx70.bpl is required by our Delphi 7 BPL at runtime
- Replies: 2
- Views: 8407
I have managed to resolve the problem by splitting the dclcrdbx70.bpl package into separate runtime and design-time packages (crdbx70.bpl and dclcrdbx70.bpl respectively).
The runtime package does not have any design-time package dependencies and can be deployed with our BPL.
None of the Devart code units needed changing, but the CRSQLConnection.pas code unit has been moved from the dclcrdbx70.bpl design-time package to the new crdbx70.bpl runtime package.
If anyone is interested, the an installer with new BPLs and revised project files for Delphi 7 can be found at http://www.trentham.net.au/downloads/ABRI%20Devart%20Fix%20setup.exe
Hopefully, we won't be using Delphi 7 for too much longer and won't have any need for the TcrSQLConnection component for the more recent versions of Delphi.
Regards,
Alex.
The runtime package does not have any design-time package dependencies and can be deployed with our BPL.
None of the Devart code units needed changing, but the CRSQLConnection.pas code unit has been moved from the dclcrdbx70.bpl design-time package to the new crdbx70.bpl runtime package.
If anyone is interested, the an installer with new BPLs and revised project files for Delphi 7 can be found at http://www.trentham.net.au/downloads/ABRI%20Devart%20Fix%20setup.exe
Hopefully, we won't be using Delphi 7 for too much longer and won't have any need for the TcrSQLConnection component for the more recent versions of Delphi.
Regards,
Alex.
- Sun 09 Jan 2011 20:33
- Forum: dbExpress driver for PostgreSQL
- Topic: dclcrdbx70.bpl is required by our Delphi 7 BPL at runtime
- Replies: 2
- Views: 8407
dclcrdbx70.bpl is required by our Delphi 7 BPL at runtime
We have an issue with the Devart dbExpress drivers for PostgreSQL in one of our BPLs under Delphi 7. In order to access the extended connection properties, we need to use the TCRSQLConnection component defined in the CRSQLConnection.pas unit in the dclcrdbx70.bpl package.
This is a major problem because dclcrdbx70.bpl seems to be behaving as both a design-time and runtime component. dclcrdbx70.bpl requires the following BPLs and all of their associated dependencies:
* dbexpress70.bpl
* dbrtl70.bpl
* dcldb70.bpl
* dcldbx70.bpl
* designdgm70.bpl
* rtl70.bpl
* vcl70.bpl
* vclactnband70.bpl
* vcldb70.bpl
We should NOT have any design-time-only packages appearing as runtime dependencies. I have checked the configuration of dclcrdbx70.dpk and it does seem to be configured as a design-time only package. I have even tried recompiling the package, but we still wind up with dclcrdbx70.bpl as a runtime dependency for our BPL.
Note that the TCRSQLConnection component seems OK to use in an executable (as opposed to a BPL) because one has the option of simply not using dclcrdbx70.bpl as a runtime package so the unit is compiled into the executable.
We were hoping to convert our Delphi 7 application suite to Devart prior to migrating to Delphi 2010, so any help would be much appreciated.
Thanks,
Alex.
This is a major problem because dclcrdbx70.bpl seems to be behaving as both a design-time and runtime component. dclcrdbx70.bpl requires the following BPLs and all of their associated dependencies:
* dbexpress70.bpl
* dbrtl70.bpl
* dcldb70.bpl
* dcldbx70.bpl
* designdgm70.bpl
* rtl70.bpl
* vcl70.bpl
* vclactnband70.bpl
* vcldb70.bpl
We should NOT have any design-time-only packages appearing as runtime dependencies. I have checked the configuration of dclcrdbx70.dpk and it does seem to be configured as a design-time only package. I have even tried recompiling the package, but we still wind up with dclcrdbx70.bpl as a runtime dependency for our BPL.
Note that the TCRSQLConnection component seems OK to use in an executable (as opposed to a BPL) because one has the option of simply not using dclcrdbx70.bpl as a runtime package so the unit is compiled into the executable.
We were hoping to convert our Delphi 7 application suite to Devart prior to migrating to Delphi 2010, so any help would be much appreciated.
Thanks,
Alex.