Board index » off-topic » BDE Merge Module and IDDA3532.dll

BDE Merge Module and IDDA3532.dll


2003-12-23 11:31:43 PM
off-topic0
Hello,
with BCB6Ent I got a merge module to use with Installshield Express 5.
Principally it works, but I manually have to change the DLL for Access97
after installation with BDEAdmin. Is there a way to change this before
building the setup (this was possible earlier with IE2 by changing the
idapi.cnf).
Thanks Andi
 
 

Re:BDE Merge Module and IDDA3532.dll

Have a look at BDEMMCFG.EXE which ships with 5.2 of the BDE MM (and maybe
prior versions too). This creates BDEMERGE.INI which allows you to
customize the aliases etc. that get created when the BDE is installed. This
is the only configuration you can do with the BDE Merge Module. You have to
distribute BDEMERGE.INI with you .msi install file. I'm not to sure on what
you can/can't do with BDEMMCFG.EXE, but if you can't do your config there,
you're kind of stuck.
You are not supposed to edit Merge Modules as doing so will likely break
subsequent installs of other software that also use the BDE Merge Module.
(It's unfortunate that Merge Modules are so easily editable once
distributed, and I don't know why MS designed them this way).
As an aside, when I looked on the Borland website, it seemed to imply that
as of 4.51 of the BDE, it uses the .dll that is appropriate for Access 97
(i.e. DAO 3.5) by default. Isn't this default what you want?
Chris
"Andreas Wehner" < XXXX@XXXXX.COM >wrote in message
Quote
Hello,

with BCB6Ent I got a merge module to use with Installshield Express 5.
Principally it works, but I manually have to change the DLL for Access97
after installation with BDEAdmin. Is there a way to change this before
building the setup (this was possible earlier with IE2 by changing the
idapi.cnf).

Thanks Andi


 

Re:BDE Merge Module and IDDA3532.dll

Hi Chris,
the ini-file has so far no possibility to set the correct dll, because
there's only possible to set the specific parameters for the alias but not
for the driver in general. I don't know why, but with my system (BCB6 new
installed) it sets the DLL for Access95 and thats my problem.
Regards Andi
"C P" < XXXX@XXXXX.COM >schrieb im Newsbeitrag
Quote
Have a look at BDEMMCFG.EXE which ships with 5.2 of the BDE MM (and maybe
prior versions too). This creates BDEMERGE.INI which allows you to
customize the aliases etc. that get created when the BDE is installed.
This
is the only configuration you can do with the BDE Merge Module. You have
to
distribute BDEMERGE.INI with you .msi install file. I'm not to sure on
what
you can/can't do with BDEMMCFG.EXE, but if you can't do your config there,
you're kind of stuck.

You are not supposed to edit Merge Modules as doing so will likely break
subsequent installs of other software that also use the BDE Merge Module.
(It's unfortunate that Merge Modules are so easily editable once
distributed, and I don't know why MS designed them this way).

As an aside, when I looked on the Borland website, it seemed to imply that
as of 4.51 of the BDE, it uses the .dll that is appropriate for Access 97
(i.e. DAO 3.5) by default. Isn't this default what you want?

Chris

"Andreas Wehner" < XXXX@XXXXX.COM >wrote in message
news:bs9n6e$b4a3k$ XXXX@XXXXX.COM ...
>Hello,
>
>with BCB6Ent I got a merge module to use with Installshield Express 5.
>Principally it works, but I manually have to change the DLL for Access97
>after installation with BDEAdmin. Is there a way to change this before
>building the setup (this was possible earlier with IE2 by changing the
>idapi.cnf).
>
>Thanks Andi
>
>


 

{smallsort}

Re:BDE Merge Module and IDDA3532.dll

I just checked my XP Laptop (which had the BDE installed from an install I
built that use the BDE Ent. 5.2 MM). You're correct - it does default to
the 3.0 DAO driver?!? The best suggestion I have is to look at the BDE API
calls. Maybe your app can make this change via the BDE API automatically
when it runs. I've used the BDE API a bit, but not enough to know how to do
this. Maybe Bill Todd will jump in here.
Alternatively, if your BDE settings are being stored in the registry, it
looks like the info you want is stored in
"HKEY_LOCAL_MACHINE\Software\Borland\Database
Engine\Settings\DRIVERS\MSACCESS\INIT\DLL32". It may not be safe to edit
this value directly in the registry. I'm a bit unfamiliar with what
is/isn't in idapi.cfg, and I think it depends on whether or not it's set to
be for 16/32 or 32-bit only of the BDE. However, it may be worth looking
into this if you can't get to the setting through the BDE API. Be _very_
careful if you edit this directly in the registry. I've seen a number of
posts warning here that a large number of BDE problems are caused by people
directly messing w/ the BDE registry settings.
"Andreas Wehner" < XXXX@XXXXX.COM >wrote in message
Quote
Hi Chris,

the ini-file has so far no possibility to set the correct dll, because
there's only possible to set the specific parameters for the alias but not
for the driver in general. I don't know why, but with my system (BCB6 new
installed) it sets the DLL for Access95 and thats my problem.

Regards Andi



"C P" < XXXX@XXXXX.COM >schrieb im Newsbeitrag
news: XXXX@XXXXX.COM ...
>Have a look at BDEMMCFG.EXE which ships with 5.2 of the BDE MM (and
maybe
>prior versions too). This creates BDEMERGE.INI which allows you to
>customize the aliases etc. that get created when the BDE is installed.
This
>is the only configuration you can do with the BDE Merge Module. You
have
to
>distribute BDEMERGE.INI with you .msi install file. I'm not to sure on
what
>you can/can't do with BDEMMCFG.EXE, but if you can't do your config
there,
>you're kind of stuck.
>
>You are not supposed to edit Merge Modules as doing so will likely break
>subsequent installs of other software that also use the BDE Merge
Module.
>(It's unfortunate that Merge Modules are so easily editable once
>distributed, and I don't know why MS designed them this way).
>
>As an aside, when I looked on the Borland website, it seemed to imply
that
>as of 4.51 of the BDE, it uses the .dll that is appropriate for Access
97
>(i.e. DAO 3.5) by default. Isn't this default what you want?
>
>Chris
>
>"Andreas Wehner" < XXXX@XXXXX.COM >wrote in message
>news:bs9n6e$b4a3k$ XXXX@XXXXX.COM ...
>>Hello,
>>
>>with BCB6Ent I got a merge module to use with Installshield Express 5.
>>Principally it works, but I manually have to change the DLL for
Access97
>>after installation with BDEAdmin. Is there a way to change this before
>>building the setup (this was possible earlier with IE2 by changing the
>>idapi.cnf).
>>
>>Thanks Andi
>>
>>
>
>


 

Re:BDE Merge Module and IDDA3532.dll

I think it would be better to get it fixed within the installation of the
BDE on the target system rather to manipulate it after installation. I also
tried to change the idapi.cnf and idapi32.cfg which are built by
Installshield out of the merge module, but no change.
Regards Andi
"C P" < XXXX@XXXXX.COM >schrieb im Newsbeitrag
Quote
I just checked my XP Laptop (which had the BDE installed from an install I
built that use the BDE Ent. 5.2 MM). You're correct - it does default to
the 3.0 DAO driver?!? The best suggestion I have is to look at the BDE
API
calls. Maybe your app can make this change via the BDE API automatically
when it runs. I've used the BDE API a bit, but not enough to know how to
do
this. Maybe Bill Todd will jump in here.

Alternatively, if your BDE settings are being stored in the registry, it
looks like the info you want is stored in
"HKEY_LOCAL_MACHINE\Software\Borland\Database
Engine\Settings\DRIVERS\MSACCESS\INIT\DLL32". It may not be safe to edit
this value directly in the registry. I'm a bit unfamiliar with what
is/isn't in idapi.cfg, and I think it depends on whether or not it's set
to
be for 16/32 or 32-bit only of the BDE. However, it may be worth looking
into this if you can't get to the setting through the BDE API. Be _very_
careful if you edit this directly in the registry. I've seen a number of
posts warning here that a large number of BDE problems are caused by
people
directly messing w/ the BDE registry settings.

 

Re:BDE Merge Module and IDDA3532.dll

My app currently checks the state of "LOCAL SHARE" and offers to set it
'properly' when my app starts. (If they don't allow me to set it to "True",
then I don't allow my app to run). This works great, and ensures that if
users mess with BDE Admin at some point, I can catch anything they may have
broken. If I had only done this during the install, I wouldn't be protected
later. I'm not sure why you think it's bad to set this stuff after
installation?
Regardless, you really shouldn't be messing with Merge Modules, or stuff
that Merge Modules add to your install. You risk breaking other installs
using the same Merge Module. I think this is partly why Windows Installer
tools merge the Merge Modules only after you've built your install.
Typically, when you're creating your .msi file, you don't get to see
anything from any Merge Modules (other than the fact that you want to
include them). It's only after all your tweaking on the .msi file is done
that the Merge Modules are compiled into your .msi file, when it's less
likely you'll alter something relating to the Merge Modules. One of the key
ideas behind a Merge Module, is that you can build an install that installs
the BDE and your app. You can determine how your files get installed.
Borland can determine absolutely how it's BDE gets installed, in order to
ensure that many people can safely install/uninstall it on the same
computer. (At least that's the theory). If you adjust any of the
BDE-related stuff in your install you're breaking the rules. (Again I don't
know why MS designed Merge Modules such that they _could_ altered, when
really they shouldn't ever be).
Having finished my rant, I expect that replacing the original idapi.cfg in
your install (as provided by the Merge Module) _probably_ won't break
anything. But in this case, it really depends on what Borland's custom
actions do with the various BDE files in the install. I _suspect_ that
idapi.cfg, idapi.cnf only get installed if they don't already exist on the
target machine. If this is the case, then your updated versions won't have
any impact. I'd also guess that the Borland custom actions use the
BDEMERGE.INI (if present) to add aliases to the existing/installed
idapi.cfg, but other than that there's no merging or anything of the
idapi.cfg file included in your install files.
"Andreas Wehner" < XXXX@XXXXX.COM >wrote in message
Quote
I think it would be better to get it fixed within the installation of the
BDE on the target system rather to manipulate it after installation. I
also
tried to change the idapi.cnf and idapi32.cfg which are built by
Installshield out of the merge module, but no change.

Regards Andi


"C P" < XXXX@XXXXX.COM >schrieb im Newsbeitrag
news: XXXX@XXXXX.COM ...
>I just checked my XP Laptop (which had the BDE installed from an install
I
>built that use the BDE Ent. 5.2 MM). You're correct - it does default
to
>the 3.0 DAO driver?!? The best suggestion I have is to look at the BDE
API
>calls. Maybe your app can make this change via the BDE API
automatically
>when it runs. I've used the BDE API a bit, but not enough to know how
to
do
>this. Maybe Bill Todd will jump in here.
>
>Alternatively, if your BDE settings are being stored in the registry, it
>looks like the info you want is stored in
>"HKEY_LOCAL_MACHINE\Software\Borland\Database
>Engine\Settings\DRIVERS\MSACCESS\INIT\DLL32". It may not be safe to
edit
>this value directly in the registry. I'm a bit unfamiliar with what
>is/isn't in idapi.cfg, and I think it depends on whether or not it's set
to
>be for 16/32 or 32-bit only of the BDE. However, it may be worth
looking
>into this if you can't get to the setting through the BDE API. Be
_very_
>careful if you edit this directly in the registry. I've seen a number
of
>posts warning here that a large number of BDE problems are caused by
people
>directly messing w/ the BDE registry settings.
>


 

Re:BDE Merge Module and IDDA3532.dll

Hi Chris,
of course you're right. The only problem for me is that most people use
Access97 and tis DB needs the idda3532.dll and not the one for Access95
which is the standard installation. However Borland and Installshield told
the people how to chnage the standard settings by default with the
Installshield2 and it worked absolutely fine. Viewing it from the customer
of an app, he wants to install the app and it should work normally. leaving
it in the the standard way this would mean to tell the customer to opend the
BDEAdmin, got to the Config, open the driver for Access and change the
DLL-Setting. I can tell this to an administrator but not to a normal user.
If there is a possibility to tell my installation program to make this
change automatically everything would be fine.
But as you've seen in the other thread I'm thinking of a conversion of my
complete app from BDE to ADO without having tis problem in the future. I
hope it will be done with just changing the vcl components and it runs. We
will see.
It would be even easier if the customers wouldn't like Access databases so
much.
Regards and merry christmas from Munich,
Andi
"C P" < XXXX@XXXXX.COM >schrieb im Newsbeitrag
Quote
My app currently checks the state of "LOCAL SHARE" and offers to set it
'properly' when my app starts. (If they don't allow me to set it to
"True",
then I don't allow my app to run). This works great, and ensures that if
users mess with BDE Admin at some point, I can catch anything they may
have
broken. If I had only done this during the install, I wouldn't be
protected
later. I'm not sure why you think it's bad to set this stuff after
installation?

Regardless, you really shouldn't be messing with Merge Modules, or stuff
that Merge Modules add to your install. You risk breaking other installs
using the same Merge Module. I think this is partly why Windows Installer
tools merge the Merge Modules only after you've built your install.
Typically, when you're creating your .msi file, you don't get to see
anything from any Merge Modules (other than the fact that you want to
include them). It's only after all your tweaking on the .msi file is done
that the Merge Modules are compiled into your .msi file, when it's less
likely you'll alter something relating to the Merge Modules. One of the
key
ideas behind a Merge Module, is that you can build an install that
installs
the BDE and your app. You can determine how your files get installed.
Borland can determine absolutely how it's BDE gets installed, in order to
ensure that many people can safely install/uninstall it on the same
computer. (At least that's the theory). If you adjust any of the
BDE-related stuff in your install you're breaking the rules. (Again I
don't
know why MS designed Merge Modules such that they _could_ altered, when
really they shouldn't ever be).

Having finished my rant, I expect that replacing the original idapi.cfg in
your install (as provided by the Merge Module) _probably_ won't break
anything. But in this case, it really depends on what Borland's custom
actions do with the various BDE files in the install. I _suspect_ that
idapi.cfg, idapi.cnf only get installed if they don't already exist on the
target machine. If this is the case, then your updated versions won't
have
any impact. I'd also guess that the Borland custom actions use the
BDEMERGE.INI (if present) to add aliases to the existing/installed
idapi.cfg, but other than that there's no merging or anything of the
idapi.cfg file included in your install files.


"Andreas Wehner" < XXXX@XXXXX.COM >wrote in message
news:bsaaaj$amar5$ XXXX@XXXXX.COM ...
>I think it would be better to get it fixed within the installation of
the
>BDE on the target system rather to manipulate it after installation. I
also
>tried to change the idapi.cnf and idapi32.cfg which are built by
>Installshield out of the merge module, but no change.
>
>Regards Andi
>
>
>"C P" < XXXX@XXXXX.COM >schrieb im Newsbeitrag
>news: XXXX@XXXXX.COM ...
>>I just checked my XP Laptop (which had the BDE installed from an
install
I
>>built that use the BDE Ent. 5.2 MM). You're correct - it does default
to
>>the 3.0 DAO driver?!? The best suggestion I have is to look at the
BDE
>API
>>calls. Maybe your app can make this change via the BDE API
automatically
>>when it runs. I've used the BDE API a bit, but not enough to know how
to
>do
>>this. Maybe Bill Todd will jump in here.
>>
>>Alternatively, if your BDE settings are being stored in the registry,
it
>>looks like the info you want is stored in
>>"HKEY_LOCAL_MACHINE\Software\Borland\Database
>>Engine\Settings\DRIVERS\MSACCESS\INIT\DLL32". It may not be safe to
edit
>>this value directly in the registry. I'm a bit unfamiliar with what
>>is/isn't in idapi.cfg, and I think it depends on whether or not it's
set
>to
>>be for 16/32 or 32-bit only of the BDE. However, it may be worth
looking
>>into this if you can't get to the setting through the BDE API. Be
_very_
>>careful if you edit this directly in the registry. I've seen a number
of
>>posts warning here that a large number of BDE problems are caused by
>people
>>directly messing w/ the BDE registry settings.
>>
>
>


 

Re:BDE Merge Module and IDDA3532.dll

Windows Installer does have a lot of power, but also a lot of downsides (in
my opinion). I think what you're seeing is a result of some. If you can
find a way to modify the setting using the BDE API, then you could do one of
two things:
1) Have your app change the (and set if necessary) the setting
automatically. I understand you don't want the user to have to mess with
the BDE Admin, and if the BDE API approach will work, then your users won't
have to touch the BDE Admin.
2) You could create a custom action in your install that does the above
(i.e. uses the BDE API to change the BDE settings). You'll have to make
sure that this custom action is scheduled to fire after the BDE files have
been installed. You'll also probably need a more sophisticated tool than
the InstallShield that comes with Delphi to do this. Orca is free from
Microsoft and allows you to edit .msi files. I use Orca and Wise for
Windows Installer. You could also look at one of the more expensive
InstallShield options.
Just to be clear, when I refer to the BDE API, I'm not talking about BDE
Admin. (Some things you said in your last post made me unsure if you were
aware I wasn't suggesting you have the users manually do stuff in BDE
Admin). There is a reference to the BDE API functions in the, "Borland
Database Engine Online Reference", help file. (Well, that's what I have
with Delphi 5).
Merry Christmas to you too,
Chris
"Andreas Wehner" < XXXX@XXXXX.COM >wrote in message
Quote
Hi Chris,

of course you're right. The only problem for me is that most people use
Access97 and tis DB needs the idda3532.dll and not the one for Access95
which is the standard installation. However Borland and Installshield told
the people how to chnage the standard settings by default with the
Installshield2 and it worked absolutely fine. Viewing it from the customer
of an app, he wants to install the app and it should work normally.
leaving
it in the the standard way this would mean to tell the customer to opend
the
BDEAdmin, got to the Config, open the driver for Access and change the
DLL-Setting. I can tell this to an administrator but not to a normal user.

If there is a possibility to tell my installation program to make this
change automatically everything would be fine.

But as you've seen in the other thread I'm thinking of a conversion of my
complete app from BDE to ADO without having tis problem in the future. I
hope it will be done with just changing the vcl components and it runs. We
will see.

It would be even easier if the customers wouldn't like Access databases so
much.

Regards and merry christmas from Munich,

Andi


"C P" < XXXX@XXXXX.COM >schrieb im Newsbeitrag
news:3fe8b6e9$ XXXX@XXXXX.COM ...
>My app currently checks the state of "LOCAL SHARE" and offers to set it
>'properly' when my app starts. (If they don't allow me to set it to
"True",
>then I don't allow my app to run). This works great, and ensures that
if
>users mess with BDE Admin at some point, I can catch anything they may
have
>broken. If I had only done this during the install, I wouldn't be
protected
>later. I'm not sure why you think it's bad to set this stuff after
>installation?
>
>Regardless, you really shouldn't be messing with Merge Modules, or stuff
>that Merge Modules add to your install. You risk breaking other
installs
>using the same Merge Module. I think this is partly why Windows
Installer
>tools merge the Merge Modules only after you've built your install.
>Typically, when you're creating your .msi file, you don't get to see
>anything from any Merge Modules (other than the fact that you want to
>include them). It's only after all your tweaking on the .msi file is
done
>that the Merge Modules are compiled into your .msi file, when it's less
>likely you'll alter something relating to the Merge Modules. One of the
key
>ideas behind a Merge Module, is that you can build an install that
installs
>the BDE and your app. You can determine how your files get installed.
>Borland can determine absolutely how it's BDE gets installed, in order
to
>ensure that many people can safely install/uninstall it on the same
>computer. (At least that's the theory). If you adjust any of the
>BDE-related stuff in your install you're breaking the rules. (Again I
don't
>know why MS designed Merge Modules such that they _could_ altered, when
>really they shouldn't ever be).
>
>Having finished my rant, I expect that replacing the original idapi.cfg
in
>your install (as provided by the Merge Module) _probably_ won't break
>anything. But in this case, it really depends on what Borland's custom
>actions do with the various BDE files in the install. I _suspect_ that
>idapi.cfg, idapi.cnf only get installed if they don't already exist on
the
>target machine. If this is the case, then your updated versions won't
have
>any impact. I'd also guess that the Borland custom actions use the
>BDEMERGE.INI (if present) to add aliases to the existing/installed
>idapi.cfg, but other than that there's no merging or anything of the
>idapi.cfg file included in your install files.
>
>
>"Andreas Wehner" < XXXX@XXXXX.COM >wrote in message
>news:bsaaaj$amar5$ XXXX@XXXXX.COM ...
>>I think it would be better to get it fixed within the installation of
the
>>BDE on the target system rather to manipulate it after installation. I
>also
>>tried to change the idapi.cnf and idapi32.cfg which are built by
>>Installshield out of the merge module, but no change.
>>
>>Regards Andi
>>
>>
>>"C P" < XXXX@XXXXX.COM >schrieb im Newsbeitrag
>>news: XXXX@XXXXX.COM ...
>>>I just checked my XP Laptop (which had the BDE installed from an
install
>I
>>>built that use the BDE Ent. 5.2 MM). You're correct - it does
default
>to
>>>the 3.0 DAO driver?!? The best suggestion I have is to look at the
BDE
>>API
>>>calls. Maybe your app can make this change via the BDE API
>automatically
>>>when it runs. I've used the BDE API a bit, but not enough to know
how
>to
>>do
>>>this. Maybe Bill Todd will jump in here.
>>>
>>>Alternatively, if your BDE settings are being stored in the
registry,
it
>>>looks like the info you want is stored in
>>>"HKEY_LOCAL_MACHINE\Software\Borland\Database
>>>Engine\Settings\DRIVERS\MSACCESS\INIT\DLL32". It may not be safe to
>edit
>>>this value directly in the registry. I'm a bit unfamiliar with what
>>>is/isn't in idapi.cfg, and I think it depends on whether or not it's
set
>>to
>>>be for 16/32 or 32-bit only of the BDE. However, it may be worth
>looking
>>>into this if you can't get to the setting through the BDE API. Be
>_very_
>>>careful if you edit this directly in the registry. I've seen a
number
>of
>>>posts warning here that a large number of BDE problems are caused by
>>people
>>>directly messing w/ the BDE registry settings.
>>>
>>
>>
>
>