Hello,

I've been through the documentation on the website and had a look at the trial version of
DBISam etc. as well as a quick search through this newsgroup so sorry if this is an FAQ.  

Anyway, the problem:  We've got an old BDE/Paradox based app which generally is currently
installed at client sites on a single PC.  They now want the ability to have small number
of users access the database concurrently.  Due to the legacy status of the BDE and
typical support issues surrounding Paradox multi-user, it is felt that we should try to
move forward to something that is current and still being supported, but that minimises
the amount of porting and translation work.  

In particular I'm looking for something that will ideally support a "hybrid" solution,
where, if I wanted to, I can turn one of the clients (the "master") into the database
"server" and have the other clients on the network connect to the "master" in a C/S style
if I wanted to.  It looks to me like DBISam fits this bill perfectly, and am just trying
to confirm my impression. (The trial unfortunately doesn't appear to allow me to build a
prototype with this architecture, or I've done something wrong.  I get "connection
refused" from another client when trying to connect even from the same app to the server
using a "remote" connection.)  In addition it appears that one very easily can port from
DBE/Paradox to DBISam which is a bonus.

Many thanks for your comments,

Walter Prins

Hmmm OK,

I've just had a look at the ElevateDB trial as well.  It appears that it would allow this
architecture to be constructed.  To trial it I modified the CDCollector demo, by changing
the CollectorDataModule.CDCollectorEngine.EngineType to etServer (from etClient), ensuring
the ServerAddress property is blank (meaning the server binds to all local interface
addresses IIUC), changing the CDCollectorSession.EngineType to etServer (from etClient)
and setting the RemoteAddress property to the IP address of my own machine (either
127.0.0.1 or the nominal LAN address.)  However, I then received an EDatabaseError in
edbcomps.pas line 3340, "Project cdcollector.exe raised exception class EDatabaseError
with message 'Cannot connect a remote session with the server engine'"  There is an if
statement basically checking to see if the engine and session is remote and then
deliberately throws an exception.  Now, I simply commented this line out, and tried again,
and it appears to work fine... but I'm wondering why that check/exception was put in?  Why
is what I've done normally not allowed and why does the code throw an exception when you
use this setup?  From what I can tell, the setup worked flawlessly after I made this
change.  It seems to me like an unnecesary/artificial limitation, but seeing as I know
nearly nothing about this componentset yet, I may very well be wrong?

Many thanks

Walter Prins

Walter

The easier approach is its only a couple of users is to simply use fileserver (you can mix'n'match c/s & fileserver with DBISAM and ElevateDB) and hold the UNC path to the files in the program directory, or set the working directory on a shortcut.

Doing it that way the conversion is little more than a global string change from TTable to TDBISAMTable. If you use sql its a bit more but not much.


Roy Lambert

Walter,

<< It looks to me like DBISam fits this bill perfectly, and am just trying
to confirm my impression. >>

Yes, DBISAM will do what you want.

<< (The trial unfortunately doesn't appear to allow me to build a prototype
with this architecture, or I've done something wrong.  I get "connection
refused" from another client when trying to connect even from the same app
to the server using a "remote" connection.)  >>

The trial version will allow you to prototype such a configuration.  We even
provide a 5-user server that you can use for testing purposes.  If you are
getting a "connection refused" error message, then that means that the
DBISAM database server is not running or listening on the port or IP address
that you are trying to connect to.   To test a simple application, do the
following:

1) Start up the database server on your development machine.
2) In your application, drop a TDBISAMSession component on your form or data
module.
3) Set the SessionName to 'Test', the SessionType property to stRemote, and
then set the Active property to True.

You should be able to connect successfully at design-time, and you should be
able to see this one connection if you pull up the DBISAM database server
interface using the system-tray icon.  If you can't connect properly in this
type of setup, please let me know what error message you get, and I will
help you figure out what is wrong.

--
Tim Young
Elevate Software
www.elevatesoft.com

Walter,

<< I've just had a look at the ElevateDB trial as well.  It appears that it
would allow this architecture to be constructed.  To trial it I modified the
CDCollector demo, by changing the
CollectorDataModule.CDCollectorEngine.EngineType to etServer (from
etClient), ensuring the ServerAddress property is blank (meaning the server
binds to all local interface addresses IIUC), changing the
CDCollectorSession.EngineType to etServer (from etClient) and setting the
RemoteAddress property to the IP address of my own machine (either 127.0.0.1
or the nominal LAN address.)  However, I then received an EDatabaseError in
edbcomps.pas line 3340, "Project cdcollector.exe raised exception class
EDatabaseError with message 'Cannot connect a remote session with the server
engine'" >>

You've got it a little backwards.  The CDCollector application is a client
application, therefore you won't change the EngineType property, but rather
change the TEDBSession component's SessionType property to stRemote, just
like with a DBISAM application.  You simply need to make sure that you have
the ElevateDB Server running on the local machine, just like with the DBISAM
application steps that I outlined in my other message.  Once you get this
type of setup running, then you can start the ElevateDB Server (or DBISAM
database server) from a different machine, and use its IP address in the
TEDBSession.RemoteAddress property to specify the new address to connect to.

<< There is an if statement basically checking to see if the engine and
session is remote and then deliberately throws an exception.  Now, I simply
commented this line out, and tried again, and it appears to work fine... but
I'm wondering why that check/exception was put in?  Why is what I've done
normally not allowed and why does the code throw an exception when you use
this setup?  From what I can tell, the setup worked flawlessly after I made
this change.  It seems to me like an unnecesary/artificial limitation, but
seeing as I know nearly nothing about this componentset yet, I may very well
be wrong? >>

Yep, you're wrong.   It's in there because we don't allow an ElevateDB
Server to initiate remote connections to other ElevateDB servers.  When you
set EngineType=etServer, you're turning the application into an ElevateDB
Server.   With both DBISAM and ElevateDB, the engine component can be used
as a local/multi-user engine or a C/S server engine.  You can see this
architecture here in the SQL manual:

http://www.elevatesoft.com/edb1sql_architecture.htm

--
Tim Young
Elevate Software
www.elevatesoft.com

Hello Tim,

Thanks for your response.  Please see my comment(s)/further questions below, thanks!

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

>Yep, you're wrong.   It's in there because we don't allow an ElevateDB
>Server to initiate remote connections to other ElevateDB servers.  When you
>set EngineType=etServer, you're turning the application into an ElevateDB
>Server.   With both DBISAM and ElevateDB, the engine component can be used
>as a local/multi-user engine or a C/S server engine.  You can see this
>architecture here in the SQL manual:
>
>http://www.elevatesoft.com/edb1sql_architecture.htm

OK... well bearing in mind that what I was trying to do was to see if its possible to
build an application that could act either as a client or a server, in one EXE file.  This
neccesitates binding the server engine into the executable etc with EngineType=etServer,
if I understand everything correctly.  Now however, when acting as server however, I was
then trying to make the client portion of that instance of the app also connect to its own
server via, if you like, a loopback connection, in identical fashion to all other clients
(who would simply use a different address to connect to, but would be identical in all
other respects -- the same EXE file in other words.)

Now, If I understand you correctly, this is actually what I achieved, but that you
actually prohibit this etc.  I still don't quite understand why you prohibit it though.
 Is there anything in particular that won't work in such a setup?

I do know/understand it's easier to just use the "client" mode/filesystem model access for
what I'm wanting to do, however I'm at this stage just wanting to confirm whether it's at
all  possible/feasible to *completely* eliminate any reliance on the filesystem
configuration of all the client machines, in essence then the only filesystem access
happening on the server (since all the actual connections to the database then is directly
via TCP/IP ), but *without* introducing the server as a seperate
application/entity/installation.  Hence why I wanto to build, if you like, a client that
can act as a server if required. (Which of course can be controlled via the application's
configuratoin.)  

Aside: The reason for wanting to ideally eliminate filesystem based semantics/access is to
thereby reduce/eliminate/avoid the kinds of problems that sometimes can occur when
multiple machines access data files accross a network (due to filesystem opportunistic
locking type issues, network blips, clients having problems halfway through file writes
and so on.)  As you no doubt know, such problems are (or used to be) sometimes common on
poorly configured/mixed Windows network setups using file based databases like Paradox.
It is possible to of course solve these problems but elimination is better than cure as
they say.  

In any event, it still seems to me like DBISam/ElevateDB is an ideal upgrade path for our
purposes, whatever artchitecture we end up using as it's pretty easy to change...

Thanks and regards,

Walter Prins

Walter,

<< OK... well bearing in mind that what I was trying to do was to see if its
possible to build an application that could act either as a client or a
server, in one EXE file. >>

Sure, that's possible.  However, you have to close the engine
(TDBISAMEngine.Active:=False) first, switch the EngineType property, and
then re-activate the engine in order to do so.

<< This neccesitates binding the server engine into the executable etc with
EngineType=etServer, if I understand everything correctly. >>

No, per the above.

<< Now however, when acting as server however, I was then trying to make the
client portion of that instance of the app also connect to its own server
via, if you like, a loopback connection, in identical fashion to all other
clients
(who would simply use a different address to connect to, but would be
identical in all other respects -- the same EXE file in other words.) >>

That is the part that won't work as things currently exist.

<< Now, If I understand you correctly, this is actually what I achieved, but
that you actually prohibit this etc.  I still don't quite understand why you
prohibit it though.  Is there anything in particular that won't work in
such a setup? >>

We prohibit it with DBISAM because it is impossible.  We prohibit it with
EDB because it hasn't been tested.  However, it should be possible to
accomplish with EDB because of the way that EDB is architected, provided
that you remove the code check that you indicated in your prior email.   I
just can't say that something weird won't happen to you if you try to run an
application that way.

<< I do know/understand it's easier to just use the "client" mode/filesystem
model access for what I'm wanting to do, however I'm at this stage just
wanting to confirm whether it's at all  possible/feasible to *completely*
eliminate any reliance on the filesystem configuration of all the client
machines, in essence then the only filesystem access happening on the server
(since all the actual connections to the database then is directly via
TCP/IP ), but *without* introducing the server as a seperate
application/entity/installation.  Hence why I wanto to build, if you like, a
client that can act as a server if required. (Which of course can be
controlled via the application's configuratoin.)  >>

You don't really need to have the server instantiate remote connections to
accomplish what you want.  Just have the client that is acting as the server
have its local sessions access the data locally (I assume that you know
which client is acting as the server), and the rest use remote sessions.

<< Aside: The reason for wanting to ideally eliminate filesystem based
semantics/access is to thereby reduce/eliminate/avoid the kinds of problems
that sometimes can occur when multiple machines access data files accross a
network (due to filesystem opportunistic locking type issues, network blips,
clients having problems halfway through file writes and so on.)  >>

Sure, that's a very worthwhile goal, and you will get what you want by using
the database server.  However, the above issues aren't present with local
sessions that are accessing the data locally just like the server on the
same machine.

<< In any event, it still seems to me like DBISam/ElevateDB is an ideal
upgrade path for our purposes, whatever artchitecture we end up using as
it's pretty easy to change... >>

That's good to hear.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hello Tim,

Thanks for the super prompt response and the clarifications.   Much appreciated.  I think
that just about answers/solves all my queries/concerns quite satisfactorily.

Cheers

Walter Prins

Hello again,

Well just one more question: Why would I choose ElevateDB over DBISam?  Evelevate is the
newer kid on the block, DBISam is older and better proven.  Someone else commented that
the buld of conversion to DBISam would be a search and replace job (due to component level
compability).  Is the same true of ElevateDB?  I'm leaning towards Elevate simply because
it's the newest and will presumeably now be the focus of development attention?  

Thanks

Walter



Walter Prins <walter.prins@hammonds-uk.com> wrote:

Hello Tim,

Thanks for the super prompt response and the clarifications.   Much appreciated.  I think
that just about answers/solves all my queries/concerns quite satisfactorily.

Cheers

Walter Prins

Walter


It might have been me that said a conversion to DBISAM was just search and replace (if not I agree with the statement). Wether ElevateDB will be depends.

My guess is the deciding factor will be usage of SQL vs Tables. If your app is mainly table based I don't think you'll have much trouble converting to either of them. If you use SQL much NOW then I think the conversion will be a lot harder.


Roy Lambert