Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread Question about the embedded version of DBIsam
Thu, Jun 1 2006 11:47 AMPermanent Link

"Ron L."
Hi,

I am looking for an embedded database engine for our analysis application.
The requirements include a good SQL implementation and TDataset
compatability - most of the work will be done by issuing SQL queries - but
some database updates are needed - where a TTable like functionality is
used.

The issue I need to resolve it concurrent use from my application. It is
currently implemented as a user-interface module that can execute multiple
instances of the analysis engine in concurrent threads. Any of the analysis
application threads can access the same database - and so can the
user-interface module. There is also a data transformation module that can
also execute concurrently and could also access the data.

The analysis engine and the data transformation module are each implemented
as an automation object in a stand-alone DLL - they are executed in-process
by the user-interface module.

We currently use MS SQL Server and everything works fine - since the
database server is external to the application and can handle multiple
connections open at once. Since we want to embed the database server for a
sepcific need - we no longer have this advantage and I do not want to
completly change our project's architecture to handle this.

My questions are:

1. Can the embedded version of dbIsam handle this easly? Do I need the C/S
version for this?
2. Do I need to implement the database access in yet another automation
object that the 3 other modules (user interface, analysis engine, data
transformation engine) will use?

Any pointers and thoughts would be helpful.


Thu, Jun 1 2006 12:17 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Ron

First point is all DBISAM implementations are embedded (possibly not if you use ODBC but I can't comment on that). You can mix fileserver and client server, have multiple instances in threads (provided you follow the isolation rules) and it will all work fine.


>The analysis engine and the data transformation module are each implemented
>as an automation object in a stand-alone DLL - they are executed in-process
>by the user-interface module.

depending on how you've done it this might give a bit of trouble. I don't use MS SQL Server so I don't know what their rules are. With DBISAM, because of the way DLLs work you'll need to open tables/queries in the DLL you can't pass them as parameters.

There've been a number of posts on the newsgroups so the best bet would be to do a quick search of them.

>1. Can the embedded version of dbIsam handle this easly? Do I need the C/S
>version for this?

Should do and no.

>2. Do I need to implement the database access in yet another automation
>object that the 3 other modules (user interface, analysis engine, data
>transformation engine) will use?

No idea without seeing what the architecture is but probably not - either drop components on a form or create in code.

I'm sure one of the resident guru's or Tim will be able to give fuller answers, but my guess is that unless you're doing something particularly clever or awkward or using MS specific SQL it shouldn't be to much of a problem.

Roy Lambert
Thu, Jun 1 2006 12:36 PMPermanent Link

"Ron L."
>
> First point is all DBISAM implementations are embedded (possibly not if
> you use ODBC but I can't comment on that). You can mix fileserver and
> client server, have multiple instances in threads (provided you follow the
> isolation rules) and it will all work fine.
>
>
>>The analysis engine and the data transformation module are each
>>implemented
>>as an automation object in a stand-alone DLL - they are executed
>>in-process
>>by the user-interface module.
>
> depending on how you've done it this might give a bit of trouble. I don't
> use MS SQL Server so I don't know what their rules are. With DBISAM,
> because of the way DLLs work you'll need to open tables/queries in the DLL
> you can't pass them as parameters.
>
> There've been a number of posts on the newsgroups so the best bet would be
> to do a quick search of them.
>

Thanks. Here is what I currently have:

1. Exe module runs the user-interface. It sometimes uses SQL queries against
the database to help the user "define" parameters for the analysis programs
they run. With MS SQL I just open an AdoConnection and a RecordSet and query
the data. Nothing too complicated there.

2. Automation object in a DLL hosts the analysis engine. It usually uses
queries issued as SQL against the database to query the data needed for the
analysis - with MS SQL Server I again use an ado connection and RecordSet
for this - but there are instances where a TDataSet derived component is
used for query and mostly updates.

3. Automation object in a DLL hosts the data transformation engine. It
sometimes uses SQL queries to update a database - no use of a dataset
derived component.

Items 2 and 3 (the automation objects) can have multiple instances active
concurrently. When working against SQL Server I always open a dedicated
connection via either an ADO Connection object or a TAdoConnection when
using datasets - so basically every thread executing has it's own
connection. Seems to work just fine.

On paper - it seems to me that if I could have a session/connection object
that is separate for each thread - I should be OK with DBIsam as well - but
what worries me is that since the database "server" code is embedded - in my
case it will be embedded in 3 modules - the exe and the 2 dlls - so I am not
sure if there might be some kind of a concurrency issue there because it is
not one code module that handles all the connection to the data.

Ron.

Thu, Jun 1 2006 2:39 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Ron


Its sounding even easier Smiley IIRC each of your automation objects is stand alone and self contained so there should be no worries.


>1. Exe module runs the user-interface. It sometimes uses SQL queries against
>the database to help the user "define" parameters for the analysis programs
>they run. With MS SQL I just open an AdoConnection and a RecordSet and query
>the data. Nothing too complicated there.

Database / Session / Query(ies) need opening - doddle

>2. Automation object in a DLL hosts the analysis engine. It usually uses
>queries issued as SQL against the database to query the data needed for the
>analysis - with MS SQL Server I again use an ado connection and RecordSet
>for this - but there are instances where a TDataSet derived component is
>used for query and mostly updates.

As above but also table if needed. You could use either a query or a table for updates

>3. Automation object in a DLL hosts the data transformation engine. It
>sometimes uses SQL queries to update a database - no use of a dataset
>derived component.

Ditto again

>Items 2 and 3 (the automation objects) can have multiple instances active
>concurrently. When working against SQL Server I always open a dedicated
>connection via either an ADO Connection object or a TAdoConnection when
>using datasets - so basically every thread executing has it's own
>connection. Seems to work just fine.
>
>On paper - it seems to me that if I could have a session/connection object
>that is separate for each thread - I should be OK with DBIsam as well - but
>what worries me is that since the database "server" code is embedded - in my
>case it will be embedded in 3 modules - the exe and the 2 dlls - so I am not
>sure if there might be some kind of a concurrency issue there because it is
>not one code module that handles all the connection to the data.

You've got it right in principle. Follow the rules in the manual and there are no problems. The fact that the engine is embedded in each of the modules is essentially the same as having several copies of the app running at the same time - its not a problem.

Even though you don't "need" the c/s version depending on the volume of data and the network traffic that would be occurring you might want it simply to speed things up a bit.

Why not download the trial version and have a play? If you hit any problems post questions and you'll get a good rewsponse.

Roy Lambert
Thu, Jun 1 2006 3:24 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Ron,

<< On paper - it seems to me that if I could have a session/connection
object that is separate for each thread - I should be OK with DBIsam as well
>>

100% correct.

<<- but  what worries me is that since the database "server" code is
embedded - in my case it will be embedded in 3 modules - the exe and the 2
dlls - so I am not sure if there might be some kind of a concurrency issue
there because it is not one code module that handles all the connection to
the data. >>

Not a problem - DBISAM can share database tables among multiple processes
and threads.  For example, a DBISAM database server (multi-threaded) can
share data with a completely separate IIS process running ISAPI DLLs or ASP
code that are also multi-threaded.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Jun 1 2006 3:24 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Ron,

<< 1. Can the embedded version of dbIsam handle this easly? >>

Yes.

<< Do I need the C/S version for this? >>

No.

<< 2. Do I need to implement the database access in yet another automation
object that the 3 other modules (user interface, analysis engine, data
transformation engine) will use? >>

Normally, most DBISAM users simply compile DBISAM into the various
applications or DLLs as necessary and don't mess around with separating it
out.  However, you can do so if you would like, in the form of a DLL or a
runtime package.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Jun 2 2006 7:34 AMPermanent Link

I just want to add one perhaps not actually relevant comment to those of
the others. If you use a form or data module, then you can put all the
DBISAM components onto it, link them up, and then add a session which you
can set an option and it will make sure all the other components use it,
and that it is uniquely named. You can then create the datamodule in the
thread and be sure you got it all right - very easy to use. But it may not
actually be relevant if your plug-in modules all have their own
independent session anyway.

/Matthew Jones/
Fri, Jun 2 2006 12:51 PMPermanent Link

"Ron L."
Thanks. Not really relevant to my situation because the threaded engines are
in a stand alone compiled module - so they can not really share
TDataModules - but the information I got here is good and I am reading the
manual as we speak. So far it looks good and I hope to order the product
very soon.

Ron.

http://www.bitogo.com/infopath/index.html
"Matthew Jones" <matthew@matthewdelme-jones.delme.com> wrote in message
news:memo.20060602123228.6088B@nothanks.nothanks.co.uk...
>I just want to add one perhaps not actually relevant comment to those of
> the others. If you use a form or data module, then you can put all the
> DBISAM components onto it, link them up, and then add a session which you
> can set an option and it will make sure all the other components use it,
> and that it is uniquely named. You can then create the datamodule in the
> thread and be sure you got it all right - very easy to use. But it may not
> actually be relevant if your plug-in modules all have their own
> independent session anyway.
>
> /Matthew Jones/

Image