dbExpress driver for Paradox
Martijn Tonies
Would there be any interest in a dbExpress driver for Paradox -
not for free, but for a small fee - to get rid of the BDE?
--
With regards,
Martijn Tonies
Database Workbench - the developer tool for InterBase & Firebird
Upscene Productions
http://www.upscene.com
Rick Carter
"Martijn Tonies" <m.tonies@upscene!nospam!.com> wrote:
>Would there be any interest in a dbExpress driver for Paradox -
>not for free, but for a small fee - to get rid of the BDE?
I'd say so. I've heard people asking about this since dbExpress
was first announced.
So, you think you can deliver something? At a "small fee," no less? :)
Rick Carter
Rick....@cincww.rcc.org
Chair, Paradox/Delphi SIG, Cincinnati PC Users Group
Martijn Tonies
Thanks for answering -
> >Would there be any interest in a dbExpress driver for Paradox -
> >not for free, but for a small fee - to get rid of the BDE?
>
> I'd say so. I've heard people asking about this since dbExpress
> was first announced.
>
> So, you think you can deliver something? At a "small fee," no less? :)
Well, I have created a dbExpress driver for Firebird, so I kinda
understand how to write a dbExpress driver (which isn't exactly
documented in any way :-)...
And I've found a component-set that can access Paradox tables
without using the BDE. So putting the two together, and working
on a couple of things, testing, bugfixing etc etc would result into
a dbExpress driver. Now, I wouldn't mind doing this - but I would
only start if there's a market and if I can sell licenses for it. And
the hard part would be if local-sql should be supported etc...
I'm selling the dbExpress driver for Firebird for 114 Euros, no
deployment fees, per single license, or 519 Euros for a site-license
for all developers, no deployment fees. So actually, pretty cheap :)
The Paradox driver would be around that price as well, I guess.
Comments?
bcb
DBExpress would perhaps change the database aswell, move away from Paradox.
But for a standalone application Paradox will still do fine.
"Martijn Tonies" <m.tonies@upscene!nospam!.com> wrote in message
news:3f01b6f2$1...@newsgroups.borland.com...
Rick Carter
"bcb" <noe...@sorry.com> wrote:
>That does sound interesting. Though most people who would migrate to
>But for a standalone application Paradox will still do fine.
Which brings up another thought. If I were doing a new stand-alone
application with local tables, I might be tempted to use the
dBASE file format, since I would know I would always have multiple
options for different ways to connect to it. I wonder what market
there might be for a dbExpress driver for .dbf tables. Then again,
I'm not sure if this is something Martijn would want to pursue,
and to appeal to the widest market it would have to support
the various types of indexes (FoxPro and Clipper, as well as dBASE).
But I'm not one who really understands marketing trends and what
everybody wants, so I hope others will join in the conversation.
Chris Pettingill
Paradox. But if a legacy app is already using Paradox, it's already got the BDE so I don't know if DBExpress would gain you much.
ADO.NET looks pretty promising to me, but I don't know enough about it or DBExpress to know how they compare. I would expect an
OLEDB driver for Paradox would have much greater marketability because then all of C#, and VB developers could also hook into legacy
apps. If there was an OLEDB driver for Paradox, then I'm sure Delphi (and Delphi .NET) could use it too.
Chris
"bcb" <noe...@sorry.com> wrote in message news:3f02...@newsgroups.borland.com...
Martijn Tonies
"Rick Carter" <Rick....@cincww.rcc.org> wrote in message
news:3f02dfaf$1...@newsgroups.borland.com...
>
> "bcb" <noe...@sorry.com> wrote:
> >That does sound interesting. Though most people who would migrate to
> >DBExpress would perhaps change the database as well, move away from Paradox.
> >But for a standalone application Paradox will still do fine.
>
> Which brings up another thought. If I were doing a new stand-alone
> application with local tables, I might be tempted to use the
> dBASE file format, since I would know I would always have multiple
> options for different ways to connect to it. I wonder what market
> there might be for a dbExpress driver for .dbf tables. Then again,
> I'm not sure if this is something Martijn would want to pursue,
> and to appeal to the widest market it would have to support
> the various types of indexes (FoxPro and Clipper, as well as dBASE).
dBase seems to be a pain :-)
> But I'm not one who really understands marketing trends and what
> everybody wants, so I hope others will join in the conversation.
I hope so too...
Writing a dbExpress is supposed to be fairly easy, but it requires
quite some research, so I would like to know if my invested time
would be appreciated and I can sell a couple of licenses.
Leslie Milburn
> > But I'm not one who really understands marketing trends and what
> > everybody wants, so I hope others will join in the conversation.
>
> I hope so too...
>
Hi Martijn,
Ok, I am buying in to the conversation :-)
The reality is that there are many many Paradox Databases out there which
simply will not go away no matter how much Borland and the publicity machine
try and tell us the BDE/SQL Links is going. Therefore, the definately is a
market out there in desktop land.
However, there are two other potential markets here already !!
1. The PDA market.
IMO Pocket SQL is overkill in a big way. The Paradox Table format is very
efficiant and very fast, its speed degradation as the database grows appears
to be neglible unlike other databases out there. If we keep the access layer
small, lets say 4K (??) then I am sure this will to some extent will be a
winner.
2. Linux.
This speaks for itself. My future direction will be towards this platform
and away from tools provided by Borland and Microsoft (I've simply had
enough). The importance of source code access cannot be stressed enough as
it at least gives you some control over your applications future (even if it
is only a recompile).
Anyway, if you decide to go ahead with this project please keep my email
address as I will be glad to help out. The main problem as I see it is that
the table format is undocumented. Having said that there is at least one
group who must know alot as they have written a Repair utility which does
*not* use the tutility library.
Finally, what functionality do you hope to provide ?
Leslie.
Martijn Tonies
> Ok, I am buying in to the conversation :-)
Good :-)
> The reality is that there are many many Paradox Databases out there which
> simply will not go away no matter how much Borland and the publicity machine
> try and tell us the BDE/SQL Links is going. Therefore, the definately is a
> market out there in desktop land.
>
> However, there are two other potential markets here already !!
>
> 1. The PDA market.
>
> IMO Pocket SQL is overkill in a big way. The Paradox Table format is very
> efficiant and very fast, its speed degradation as the database grows appears
> to be neglible unlike other databases out there. If we keep the access layer
> small, lets say 4K (??) then I am sure this will to some extent will be a
> winner.
4K = very very small - and most probably currently impossible with Delphi
or Kylix.
> 2. Linux.
>
> This speaks for itself. My future direction will be towards this platform
> and away from tools provided by Borland and Microsoft (I've simply had
> enough). The importance of source code access cannot be stressed enough as
> it at least gives you some control over your applications future (even if it
> is only a recompile).
>
> Anyway, if you decide to go ahead with this project please keep my email
> address as I will be glad to help out. The main problem as I see it is that
> the table format is undocumented. Having said that there is at least one
> group who must know alot as they have written a Repair utility which does
> *not* use the tutility library.
>
> Finally, what functionality do you hope to provide ?
Well, I've found a Delphi component set that does Paradox access. This,
combined with my knowledge and research of writing a dbExpress driver
could result in a dbExpress driver for Paradox. Why the componentset
instead of doing every Paradox thing myself? Well, because it works - and
I avoid a LOT of research and bugfixing, but can concentrate on getting
the driver to work - which, in itself, is quite the task already :)
Depending on the code/components used by the components of the
componentset, the driver will be larger/smaller. I guess.
Leslie Milburn
"Martijn Tonies" <m.tonies@upscene!nospam!.com> wrote in message
> Hi Leslie,
>
> > Ok, I am buying in to the conversation :-)
>
a
> > winner.
>
> 4K = very very small - and most probably currently impossible with Delphi
> or Kylix.
I guess this is the problem with these newer tools. I am writing my PDA
stuff in straight C. I've only just recently started, but its at around 4-6K
at the moment. EXE/DLL Size will be an issue in this particular market.
Besides, I never said it would be easy.
> > Finally, what functionality do you hope to provide ?
>
> Well, I've found a Delphi component set that does Paradox access. This,
> combined with my knowledge and research of writing a dbExpress driver
> could result in a dbExpress driver for Paradox. Why the componentset
> instead of doing every Paradox thing myself? Well, because it works - and
> I avoid a LOT of research and bugfixing, but can concentrate on getting
> the driver to work - which, in itself, is quite the task already :)
I guess I was wondering more in terms of a QBE engine or SQL engine or
whether we are just talking a very low lever table/record access layer. What
about table creation/ indexes on the fly etc etc.
In terms of implementation, My approach would be to write it is as low level
as possible (either C or simple C++) and place this code is a DLL. The
DBExpress (or other future drivers) would then simply be a wrapper around
the DLL. This would probably provide the most options in terms of other
development languages (even assembler) being able to use the product.
Just thinking aloud
Leslie.
bcb
> Which brings up another thought. If I were doing a new stand-alone
> application with local tables, I might be tempted to use the
> dBASE file format, since I would know I would always have multiple
> options for different ways to connect to it. I wonder what market
> there might be for a dbExpress driver for .dbf tables.
From reading many posts. It seems to me that more people are using Paradox
than DBase (I myself have an app using mostly paradox and a single dbase
table since dbase allows more fields). But if a DBExpress driver is released
for Paradox. Can it be that hard to convert it to work with DBase aswell?
Also the BDE works quite well, what would be the main advantages of using
DBExpress not counting BDE deployment since that for me is not as a big
issue as for others becuase I would not like to lose application
performance, so I hope it will not much worse and if it's even better then
that's great. Also I do understand the BDE is no longer being developed,
that alone is why many developers are re-thinking not to use it.
Martijn Tonies
BDE development _has_ stopped. No more new stuff. The dbExpress
driver for Paradox would - most probably - give you the opportunity
to develop with dbExpress and then throw in different drivers, like InterBase,
Paradox (for local or network access) and others. Paradox could be
a nice option for legacy applications, legacy data or companies that
don't WANT to install a server side application.
(also thinking out loud)
--
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Martijn Tonies
> > > Ok, I am buying in to the conversation :-)
> >
> > > small, lets say 4K (??) then I am sure this will to some extent will be
> a
> > > winner.
> >
> > 4K = very very small - and most probably currently impossible with Delphi
> > or Kylix.
>
> I guess this is the problem with these newer tools. I am writing my PDA
> stuff in straight C. I've only just recently started, but its at around 4-6K
> at the moment. EXE/DLL Size will be an issue in this particular market.
> Besides, I never said it would be easy.
*g*... Well, it's Delphi I do... I guess there are other specialized options
for PDAs (with regard to data storage).
> > > Finally, what functionality do you hope to provide ?
> >
> > Well, I've found a Delphi component set that does Paradox access. This,
> > combined with my knowledge and research of writing a dbExpress driver
> > could result in a dbExpress driver for Paradox. Why the componentset
> > instead of doing every Paradox thing myself? Well, because it works - and
> > I avoid a LOT of research and bugfixing, but can concentrate on getting
> > the driver to work - which, in itself, is quite the task already :)
>
> I guess I was wondering more in terms of a QBE engine or SQL engine or
> whether we are just talking a very low lever table/record access layer. What
> about table creation/ indexes on the fly etc etc.
It seems that SQL (pretty much the same as local SQL) support should be
possible. QBE -> no go. Then again, dbExpress is purely SQL based
anyway.
> In terms of implementation, My approach would be to write it is as low level
> as possible (either C or simple C++) and place this code is a DLL. The
> DBExpress (or other future drivers) would then simply be a wrapper around
> the DLL. This would probably provide the most options in terms of other
> development languages (even assembler) being able to use the product.
My approach, in this regard, would be to make it as small as possible as
well.
> Just thinking aloud
No problem - I'm just investigating as well.
Martijn Tonies
>
> "Martijn Tonies" <m.tonies@upscene!nospam!.com> wrote:
> >Would there be any interest in a dbExpress driver for Paradox -
> >not for free, but for a small fee - to get rid of the BDE?
>
> I'd say so. I've heard people asking about this since dbExpress
> was first announced.
Question though -
How would indices etc work with dbExpress? dbExpress is primarily
SQL based... Any clues?
Leslie Milburn
"Martijn Tonies" <m.tonies@upscene!nospam!.com> wrote in message
news:3f04...@newsgroups.borland.com...
> Hi Leslie,
>
> > EXE/DLL Size will be an issue in this particular market.
> > Besides, I never said it would be easy.
>
> *g*... Well, it's Delphi I do... I guess there are other specialized
options
> for PDAs (with regard to data storage).
I am not fully up to speed on the PDA environment as yet. I have taken a
look at PocketSQL which has quite a bit of overhead (and I believe no source
code). My solution so far was to create my own Tables which are similar to a
Paradox but at this time only have maintained Primary Indexes.
The DLL that does all of this is approx 25K (compiled for Win32). However,
it is *not* Paradox but is classified as proprietary, and of course is API
based - no SQL engine (a bit like BTrieve in the old days).
Delphi must (dare I suggest) be also able to create small .com like results.
A long forgotten technique is to create your own basic library routines as a
way to avoid copious amounts of unneccessary code being included with your
executable. So for example I have my own string copy, binary to String
conversion routines etc as I can guarantee they are independant of other
objects provided by say Borland or Microsoft as part of "their" standard
application framework.
> It seems that SQL (pretty much the same as local SQL) support should be
> possible. QBE -> no go. Then again, dbExpress is purely SQL based
> anyway.
The loss of QBE *could* be an issue as we are talking Paradox. I would
suggest that at the very least a QBE to SQL translator be provided. I do not
think this will be much overhead and should be in a separate DLL allowing it
as an option.
> My approach, in this regard, would be to make it as small as possible as
> well.
Yes, well 4-6K was being very optimistic;-) Seriously though, I have seen
fairly basic programs today easily hitting 1Meg which do almost nothing.
Given that DOS had only 640K memory I would suggest that if you are hitting
half this figure then it is way too much.
With regards a PDA I would target a total memory capacity of perhaps 8 Megs.
This is for *all* program and data storage for *all* applications.
Leslie.
Martijn Tonies
> > > EXE/DLL Size will be an issue in this particular market.
> > > Besides, I never said it would be easy.
> >
> > *g*... Well, it's Delphi I do... I guess there are other specialized
> options
> > for PDAs (with regard to data storage).
>
> I am not fully up to speed on the PDA environment as yet. I have taken a
> look at PocketSQL which has quite a bit of overhead (and I believe no source
> code). My solution so far was to create my own Tables which are similar to a
> Paradox but at this time only have maintained Primary Indexes.
> The DLL that does all of this is approx 25K (compiled for Win32). However,
> it is *not* Paradox but is classified as proprietary, and of course is API
> based - no SQL engine (a bit like BTrieve in the old days).
>
> Delphi must (dare I suggest) be also able to create small .com like results.
Leaving all of the VCL out is a good start :-)
> A long forgotten technique is to create your own basic library routines as a
> way to avoid copious amounts of unneccessary code being included with your
> executable. So for example I have my own string copy, binary to String
> conversion routines etc as I can guarantee they are independant of other
> objects provided by say Borland or Microsoft as part of "their" standard
> application framework.
>
> > It seems that SQL (pretty much the same as local SQL) support should be
> > possible. QBE -> no go. Then again, dbExpress is purely SQL based
> > anyway.
>
> The loss of QBE *could* be an issue as we are talking Paradox. I would
> suggest that at the very least a QBE to SQL translator be provided. I do not
> think this will be much overhead and should be in a separate DLL allowing it
> as an option.
I'll have to investigate that - I've never worked with QBE, could you
give me some pointers?
> > My approach, in this regard, would be to make it as small as possible as
> > well.
>
> Yes, well 4-6K was being very optimistic;-) Seriously though, I have seen
> fairly basic programs today easily hitting 1Meg which do almost nothing.
> Given that DOS had only 640K memory I would suggest that if you are hitting
> half this figure then it is way too much.
The 1meg apps aren't loaded in memory though :-) ... Anyway, that's what
you get with lots of complex visual components. I don't mind - and with a
PDA you know it will be more primitive.
> With regards a PDA I would target a total memory capacity of perhaps 8 Megs.
> This is for *all* program and data storage for *all* applications.
Rick Carter
"Martijn Tonies" <m.tonies@upscene!nospam!.com> wrote:
>> The loss of QBE *could* be an issue as we are talking Paradox. I would
>> suggest that at the very least a QBE to SQL translator be provided. I do not
>> think this will be much overhead and should be in a separate DLL allowing it
>> as an option.
>
>I'll have to investigate that - I've never worked with QBE, could you
>give me some pointers?
To take a look at how QBE works, look at Database Desktop which
comes with Delphi, since it's basically a scaled-down version of
Paradox 7. After creating a query, choose from the menu "Query -
Show SQL" to generate a SQL statement (doesn't work perfectly,
and usually doesn't generate the most efficient SQL query possible,
but it can be a handy way to get your SQL queries started).
QBE support in Delphi has already been implemented in the open
source rxLib components, which are now part of the JEDI VCL.
Martijn Tonies
> >> The loss of QBE *could* be an issue as we are talking Paradox. I would
> >> suggest that at the very least a QBE to SQL translator be provided. I do
not
> >> think this will be much overhead and should be in a separate DLL allowing
it
> >> as an option.
> >
> >I'll have to investigate that - I've never worked with QBE, could you
> >give me some pointers?
>
> To take a look at how QBE works, look at Database Desktop which
> comes with Delphi, since it's basically a scaled-down version of
> Paradox 7. After creating a query, choose from the menu "Query -
> Show SQL" to generate a SQL statement (doesn't work perfectly,
> and usually doesn't generate the most efficient SQL query possible,
> but it can be a handy way to get your SQL queries started).
>
> QBE support in Delphi has already been implemented in the open
> source rxLib components, which are now part of the JEDI VCL.
I get stuff like this:
SELECT DISTINCT d.OrderNo, d.CustNo, d1.OrderNo, d1.ItemNo, d1.PartNo, d1.Qty,
d1.Discount
FROM "C:\Program Files\Common Files\Borland Shared\Data\orders.db" d,
"C:\Program Files\Common Files\Borland Shared\Data\items.db" d1
WHERE
(d1.OrderNo = d.CustNo)
ORDER BY d.OrderNo, d.CustNo, d1.OrderNo, d1.ItemNo, d1.PartNo, d1.Qty,
d1.Discount
Now, what's so special about this SQL?
And this in a QBE file:
Query
ANSWER: :PRIV:ANSWER.DB
C:\Program Files\Common Files\Borland Shared\Data\orders.db | OrderNo |
| Check |
C:\Program Files\Common Files\Borland Shared\Data\orders.db | CustNo |
| Check _join1 |
C:\Program Files\Common Files\Borland Shared\Data\items.db | OrderNo |
| Check _join1 |
C:\Program Files\Common Files\Borland Shared\Data\items.db | ItemNo | PartNo |
| Check | Check |
C:\Program Files\Common Files\Borland Shared\Data\items.db | Qty |
| Check |
C:\Program Files\Common Files\Borland Shared\Data\items.db | Discount |
| Check |
EndQuery
Do people actually use these files?
Bill Todd
QBE was developed by IBM's research lab in the very early days of
relational databases as an easy to use ad hoc query language. This
happened before SQL became the standard that it is today, before GUI's
and before there were any visual SQL query builders. Paradox was
designed as the firs end user database and supported QBE from its
first version for DOS, which shipped in 1985.
The reason that Paradox users still use QBE queries is that the QBE
query optimizer is substantially better than the Local SQL optimizer
so you frequently get much better performance with QBE than with the
equivalent SQL query.
The 16 bit versions of the BDE did not have an SQL query processor.
All they had was a SQL to QBE translator. The 32 bit BDE has two
completely separate query processors, one for QBE and one for SQL, and
their capabilities are quite different.
I hope this background information clarifies why QBE is of interest
and is still used by Paradox application developers.
--
Bill (TeamB)
(TeamB cannot respond to questions received via email)
Martijn Tonies
> QBE was developed by IBM's research lab in the very early days of
> relational databases as an easy to use ad hoc query language. This
> happened before SQL became the standard that it is today, before GUI's
> and before there were any visual SQL query builders. Paradox was
> designed as the firs end user database and supported QBE from its
> first version for DOS, which shipped in 1985.
>
> The reason that Paradox users still use QBE queries is that the QBE
> query optimizer is substantially better than the Local SQL optimizer
> so you frequently get much better performance with QBE than with the
> equivalent SQL query.
> The 16 bit versions of the BDE did not have an SQL query processor.
> All they had was a SQL to QBE translator. The 32 bit BDE has two
> completely separate query processors, one for QBE and one for SQL, and
> their capabilities are quite different.
Aha - so QBE isn't "just" some front-end thingy, but some kind of
"engine" by itself. But you CAN translate QBE to SQL, right? 'Cause
that is what Database Desktop does when you hit the "Show SQL"
button, am I right here?
Excuse my ignorance, but how does one use QBE via Delphi?
> I hope this background information clarifies why QBE is of interest
> and is still used by Paradox application developers.
Yes, thank you for the background info :-)
Leslie Milburn
"Martijn Tonies" <m.tonies@upscene!nospam!.com> wrote in message
news:3f0c...@newsgroups.borland.com...
>
> Aha - so QBE isn't "just" some front-end thingy, but some kind of
> "engine" by itself. But you CAN translate QBE to SQL, right? 'Cause
> that is what Database Desktop does when you hit the "Show SQL"
> button, am I right here?
Occasionally, when I click the Show SQL it cannot produce an equivalent SQL
statement but that does not mean one doesn't exist, for some reason no
advanced logic is present to work one out, strange because QBE has a limited
no of keywords.
> Excuse my ignorance, but how does one use QBE via Delphi?
>
In terms of Delphi I will leave this to others, but if you are calling the
BDE directly it would be something like dbiQExec().
Leslie.
Chris Pettingill
Woll2Woll (Infopower) has (or had at least) a component that would allow you
to run QBE queries (TwwQBE) pretty much the same as you would a SQL query
(TQuery/TwwQuery).
Bill Todd
>"engine" by itself. But you CAN translate QBE to SQL, right? 'Cause
>that is what Database Desktop does when you hit the "Show SQL"
>button, am I right here?
Right. QBE is another query language for querying relational
databases. It is an alternative to SQL. Since both map to the same
relational database model it is possible to translate most queries
from one to the other.
>
>Excuse my ignorance, but how does one use QBE via Delphi?
With a third party QBE component. There are several around. The one I
have always used is part of the InfoPower suite. There are also
shareware ones. There may even be a freeware one or two.
francois
You should check out the Advantage local server. Translation from Paradox
to the ADT format is nearly trivial and you get support for all flavours of
dbase/clipper/foxbase etc. And its free. The Arc32 is also a fantasixt
replacement for the DBDesktop and SQL explorer. Also no Registry rubbish.
Paradox is actually OK. We run 350 installations on 1500+ pc's. Our biggest
problem is new applications corruption our installations when their install
trashes ours.
If Borland is so adamant about no further development on Paradox, then why
don't they give it to Open Source. I'm sure that all (OK most of) our small
niggles would be fixed ASAP. My biggest wish is to remove all registry
enries and just run it from an ini file.
Regards
Francois
"Chris Pettingill" <ChrisPe...@Compuserve.Com> wrote in message
Leslie Milburn
"francois" <franshATwestnetDOTcomDOTau> wrote in message
news:3f0e...@newsgroups.borland.com...
> Hi
> You should check out the Advantage local server. Translation from Paradox
> to the ADT format is nearly trivial and you get support for all flavours
of
> dbase/clipper/foxbase etc. And its free. The Arc32 is also a fantasixt
> replacement for the DBDesktop and SQL explorer. Also no Registry rubbish.
Does this actually convert the data or leave it in its native format. If you
are talking conversion, then that is an entirely different story. We are
talking about accessing the Paradox Tables in their current format.
Besides if you are going to convert then Interbase/Firebird seems like a
smarter move in the long run.
> Paradox is actually OK. We run 350 installations on 1500+ pc's. Our
biggest
> problem is new applications corruption our installations when their
install
> trashes ours.
I hope you are not still relying upon installtime aliases etc. If so, I
would strongly recommend that you change to always set the environment each
time you run. I have done this for many years now without any .cfg (and
registry) problems and I know that there are at least 5 or 6 other BDE
applications on the same machine as mine.
> If Borland is so adamant about no further development on Paradox, then why
> don't they give it to Open Source. I'm sure that all (OK most of) our
small
> niggles would be fixed ASAP.
Of course all would be fixed but unfortunately its functionality would no
doubt become more powerful (I would definitely give it a good go). This I
believe is the *real* reason why the BDE will never become open source. Of
course they could also be embarrassed about how crap their coding style is
;-)
> My biggest wish is to remove all registry
> enries and just run it from an ini file.
>
Why ? I fail to see where the problem lies in using the registry. In fact,
give the number of issues with the actual installation of the BDE (why this
is the case I don't know), I for one am glad that the settings are in one
known place rather than (potentially) being spread all the machine in a
variety of ini files. This would certainly spell disaster.
Leslie.
francois
This should actually be another thead but ...
1) Why get rid of registry entries?
When you install the BDE on XP some keys, like INIT below Paradox and INIT
below System have their permissions set to deny access. Well abot 50 % of
the time we have to manually take ownership of the key (logged in as Admin)
and only after that can we get the whole brach set to alow full control to
everyone. I could not understand why the JCL library's
AllowRegKeyForEveryone could not fix it until I found a utility called
SetACL with which you can do that from a batchfile. However, the buglist of
SetACL states that sometimes keys cannot be automatically changed because
their ACE is owned by another user. I have confirmed, with my manual
routine that those two keys are always not owned by the Administrator (about
50% of the time). Even regsvr32 bdeinst.dll and the BDEinfo utilty fails to
make it happen in those cases. It even happens on Win2K but not so often.
Now the data stored in those registry keys could just as well have been
located in an inifile.
2) The dynamic aliases really work!
To say I was sceptical would be an understatement but I now have a 'Hidden'
PDoxusers.NET sitting in my application folder and since that is the only
place the executable may be run from it can easily set the NetDir. I really
marvel at how neat a solution that can be. I'll start rolling it out RSN.
One strange phenomenon though: While my program is running, the BDEAdmin
will only run if I make the 'start in path' of the shortcut the same as the
NetDir folder! Otherwise I get a $210C error. I assume that is because the
netdir of the ruling idapi.cfg was set to another folder.
Anyway, I thank you for the sharing your method.
Regards
Francois
"Leslie Milburn" <CD...@bigpond.com> wrote in message
Chris Pettingill
> This should actually be another thead but ...
> 1) Why get rid of registry entries?
> When you install the BDE on XP some keys, like INIT below Paradox and INIT
> below System have their permissions set to deny access. Well abot 50 % of
> the time we have to manually take ownership of the key (logged in as
Admin)
> and only after that can we get the whole brach set to alow full control to
> everyone. I could not understand why the JCL library's
> AllowRegKeyForEveryone could not fix it until I found a utility called
> SetACL with which you can do that from a batchfile. However, the buglist
of
> SetACL states that sometimes keys cannot be automatically changed because
> their ACE is owned by another user. I have confirmed, with my manual
> routine that those two keys are always not owned by the Administrator
(about
> 50% of the time). Even regsvr32 bdeinst.dll and the BDEinfo utilty fails
to
> make it happen in those cases. It even happens on Win2K but not so often.
> Now the data stored in those registry keys could just as well have been
> located in an inifile.
To me, this sounds like a problem with the BDE install or the way the BDE is
working with Win2k/XP security. It's understandable to me that the BDE
might not work 100% properly on XP and Win2K, since (AFAIK) it was not
developed to work on XP or 2000. I think the registry is preferable by
far - as long as it's being used properly.
Leslie Milburn
"Chris Pettingill" <ChrisPe...@Compuserve.Com> wrote in message
>
> To me, this sounds like a problem with the BDE install or the way the BDE
is
> working with Win2k/XP security. It's understandable to me that the BDE
> might not work 100% properly on XP and Win2K, since (AFAIK) it was not
> developed to work on XP or 2000. I think the registry is preferable by
> far - as long as it's being used properly.
Hi Chris,
Yes you are correct the BDE does not allow for Win2k or XP and this is where
the problem lies. The Registry branch the BDE uses is by default protected
under Win2K and XP (not sure about NT) and is only allowed to be changed by
the Administrator.
If it is the Administrator who is installing the BDE software there is NO
problem. If a non-Administrator tries then it fails. This is easily
rectified by the Administrator who can change the permissions on that
particular registry branch.
Now the good news is that if you set the BDE accordingly, once installed the
BDE can be instructed to save its settings in the config file as well as the
registry (or perhaps it is the config file only - I forget) and therefore
permissions may not needed beyond installation time.
Leslie.
francois
Bad news if you think NO Problem. The cited installation problem definitely
happens under Administrator. We initially thought it was because the user
only gave himself admin permissions. Also the BDE won't run unless the keys
below INIT for both Paradox and System were visible. Try it yourself!. If
it is not visible it also cannot just be changed from inside the regedit.
You have to go through Advanced and make Admin the owner of that key or else
it just says access denied. Now we have done around 200 installs on XP
machines in the last 18 months and some worked and some needed this massage
to operate correctly. This is also not a BDE problem but rather a M$
problem as well as an installer problem. Maybe the way that the OEM XP was
installed causes the problem. Anyway I have not seen any installer, and I
have try nearly all, that can recover from this situation without manual
intervention. Or maybe it just happens in Perth....
"Leslie Milburn" <CD...@bigpond.com> wrote in message
news:3f16...@newsgroups.borland.com...
Chris Pettingill
had 200 XP installs yet. It sounds to me like some other software had
already installed those keys under a different user name. Maybe the
computers shipped with Corel office or something, and the ownership by a
different user was set up by this prior install? Then, when your install
came along, it wouldn't (and I would say shouldn't) have the rights to
change the ownership of those keys. Also, in Windows Installer, you can
impersonate other users at times if you need to. I know there are some bugs
in the BDE 5.2 merge module. Maybe there are some problems with the way
impersonation has been used in the merge module. If the BDE merge modules
were bug-free, and everyone was using the Merge Modules to install the BDE,
then things should be OK. But when people install the BDE (or any other
software) on XP with older technologies (i.e. not Windows Installer) there
are bound to be problems - there's a ton of new stuff in XP that you need to
consider when building an install. I just checked the documentation for
Windows Installer, and you can choose which users have access to registry
keys in a locked down environment. The documentation goes on to say, "[i]t
is recommended that the system administrator's local group be included in
all access control lists. This ensures that the system administrator is able
to access and maintain objects" (this is referring to setting up the
permissions for registry keys, files etc. that are installed by Windows
Installer).
I would be curious to know if you looked for those keys before you installed
the BDE to see if they were already there and owned by a different user. It
sounds to me like the original install for the BDE on some of the XP
machines was not authored properly (such that nothing was done to ensure the
system admins had permissions to all BDE keys), and as a result your
subsequent installs had problems.
"francois" <franshATwestnetDOTcomDOTau> wrote in message
Chris Pettingill
stuff (and I was hungry), so let me try again...
Any per-machine install should generally only be run by an administrator.
So, a BDE install (which does need to be a per-machine install) should then
have access to the part of the hive where the BDE keys are. Now, the ACL's
that control each key are absolute, so if Administrator or Administrators
are not part of the ACL for the key, then they shouldn't have access to it.
If you want good security, this makes sense. This means neither the
installer, nor regedit, nor anything else should be able to change the keys,
unless they are running as a user that is in the ACL for that key. With
Windows Installer (and other installers I assume) you can set the
users/groups in the ACL for a key (assuming you're running as a user with
permissions to alter the key). The Windows Platform SDK suggests that you
should generally always add Administrators or at least Administrator to the
ACL for any keys you are securing. It sounds like on your problem machine,
a prior install (or other utility) created the crucial BDE keys, but did not
obey the rule of adding Adminstrator or Administrators to the ACL for the
keys. This then is a flaw in the actual install. I know there are bugs in
the BDE 5.2 Merge Module, so it's possible the problem is there. But, it
could also be due to some other install (i.e. Corel's install of
Paradox/Corel Office). I bet if you installed on machines that didn't
already have the BDE installed, your install would work fine every time.
I think everything is working the way it is supposed to, and you've just had
to deal with a bad prior install that someone else has run.
Also, the BDE in my experience runs fine for non-admin users. The BDE Admin
utility does require that you be logged in as an admin to change certain
things, and I think that makes sense too. Since the BDE was built before
all of this tight security, maybe not much thought was given to what
settings non-admin users might need to alter, but in my experience you can
do what you need to get done without too much trouble. It would probably be
better though if when you tried to start the BDE Admin, a warning would come
up and not allow you to run the admin if you were not logged in with admin
rights.
"Chris Pettingill" <ChrisPe...@Compuserve.Com> wrote in message
news:3f16...@newsgroups.borland.com...
Leslie Milburn
> I think my answer was a little incoherent. I am pretty new to this
security
> stuff (and I was hungry), so let me try again...
It all made sense to me:-)
Anyway, I think you may have identified the problem - the Merge Module. I do
not use the Merge Module (and never will), I prefer Installshield Express
(and even then not the latest). My total installs of the BDE total around
1400 and in *all* cases it was when the User was not logged in as
Administrator that the failure happened.
Leslie.
Chris Pettingill
no entries in the LockPermissions table, so I don't think the issue is in
this Merge Module. There have been other versions of the MM though. And it
might not be the Merge Module at all if Francois is not using one - it could
be whatever install tool is being used is doing something wrong. Regardless
of the install tool, I believe you always need to be logged in as an Admin
to install the BDE (NT/2000/XP). From my experience, non-users can use the
BDE without being admin, but you must be an admin to run/change settings in
the BDE Administrator. I have probably only had about 20-40 XP installs so
far, and many of those would be with users running with admin rights all the
time. However, in my own testing as a non-admin, I've not yet had problems
running my BDE/Paradox app on XP. I would be curious to know what install
tool Francois is using; I want to make sure that I don't run into his
problem.
"Leslie Milburn" <CD...@bigpond.com> wrote in message
Chris Pettingill
causing the issue. And who knows what that other install was done with. I
wonder if all the problem computers had Corel office, or some other app
using the BDE already installed, before Francois installed his app. I don't
know if an install would give an error if it couldn't change the value of an
pre-existing key - I expect most wouldn't compain. So, the problem wouldn't
have been evident until trying to use the app. I'd also expect though that
the previously installed app that uses the BDE might not run well (unless it
was impersonating the user that was allowed access to the BDE keys). But,
with Corel Office, most people just use WordPerfect I think, and probably
woulndn't notice if the BDE wasn't working.
"Chris Pettingill" <ChrisPe...@Compuserve.Com> wrote in message
news:3f17ef48$1...@newsgroups.borland.com...
Leslie Milburn
"Chris Pettingill" <ChrisPe...@Compuserve.Com> wrote in message
news:3f17...@newsgroups.borland.com...
> causing the issue. And who knows what that other install was done with.
This is also a valid point. For example, I have found that the 2.51 (16 bit
IDAPI) cfg file is not compatible with the BDE32. When BDE32 is installed it
"finds" the 2.51 cfg file and attempts to do a merge. The problem is that
the resultant merged cfg file causes the BDE32 to crash. The cfg file from
16 bit IDAPI 2.52 does not cause this problem.
I might also point out for the record, that similar incompatibilies exists
between the cfg file used/create by ODAPI (the post Paradox Engine but pre
BDE system), although they are more subtle - such as INIT options sometimes
not being present.
Leslie.