Hi Godfrey

I've been using RemObjects/DataAbstract since about 2004 and am very
happy with it (it's a 3-tier architecture). The RO guys themselves will
admit that their documentation needs to be improved, but this is one of
the things they're working on at the moment. I'm a great fan of a 3-tier
architecture for a number of reasons, one of which is security since
there's no direct access to the database. There's also a Javascript
client for RO/DA that I've been using with EWB (I posted some simple demos).

I've never used Datasnap so don't know how it would be used with a
browser client. For example, with RO/DA you can create an ISAPI DLL for
use with IIS, or use an RO/DA server with its built-in web server to
deliver the web content (incl the EWB Javascript). I've been using the
latter approach and it works well.

Cheers, Bob




On 04/04/2012 07:17, Godfrey Fletcher wrote:
> yes it's fair to say that some of the data access
> frameworks have a steep learning curve, but are very powerful.
>
> Hi Bob
>
> What data access framework do you recommend?
>
> Can Datasnap be used for this?
>
> Thks
> Godfrey
>

Hi Bob,

<< I've been using RemObjects/DataAbstract since about 2004 and am very
happy with it (it's a 3-tier architecture). >>

I know this is a bit off-topic and is definitely the wrong forum, but have you used RemObjects SDK with ElevateDB, and, if so, are there any limitations like loss of any functionality using it this way as opposed to connecting directly to ElevateDB?

Regards,

Steve

Hi Steve

I haven't used it with ElevateDB but I'd say the real difference will be
in the disconnected nature of 3-tier architectures, rather than any
issue with RO/DA omitting functionality. Connecting directly to the db
with a TDataset derivative, for example, or a standard 2-tier
client-server architecture will give lots of direct control and "live"
datasets, but that's not advisable for public-facing apps.

The type of web app created with EWB is also disconnected in nature -
edits made in the browser are not reflected in the database until the
changes are committed via some SQL.

A great advantage of RO/DA is that most or all of the SQL work is done
for you. E.g. in a master-detail insert with an autoinc PK/FK you just
need to specify the FK relationship on the server, update the two tables
on the client and call ApplyUpdates. The server generates all SQL
required to populate the detail table with the correct FK value.

Cheers, Bob



On 04/04/2012 22:51, Steve Gill wrote:
> Hi Bob,
>
> <<  I've been using RemObjects/DataAbstract since about 2004 and am very
> happy with it (it's a 3-tier architecture).>>
>
> I know this is a bit off-topic and is definitely the wrong forum, but have you used RemObjects SDK with ElevateDB, and, if so, are there any limitations like loss of any functionality using it this way as opposed to connecting directly to ElevateDB?
>
> Regards,
>
> Steve
>

Hi Bob,

<< I haven't used it with ElevateDB but I'd say the real difference will be
in the disconnected nature of 3-tier architectures, rather than any
issue with RO/DA omitting functionality. Connecting directly to the db
with a TDataset derivative, for example, or a standard 2-tier
client-server architecture will give lots of direct control and "live"
datasets, but that's not advisable for public-facing apps.

The type of web app created with EWB is also disconnected in nature -
edits made in the browser are not reflected in the database until the
changes are committed via some SQL.

A great advantage of RO/DA is that most or all of the SQL work is done
for you. E.g. in a master-detail insert with an autoinc PK/FK you just
need to specify the FK relationship on the server, update the two tables
on the client and call ApplyUpdates. The server generates all SQL
required to populate the detail table with the correct FK value.  >>

Thanks for that.  I'll have to investigate further as I'm using stored procedures extensively with ElevateDB.  What initially attracted me to RO is ROZeroConf.  I like the idea of a client app being able to find the server app, although I have managed to implement something "similar" using IP multicasting.  ROZeroConf sounds a lot more powerful.

Regards,

Steve

Hi Steve

>I'm using stored procedures extensively with ElevateDB

There's no problem with that - although RO/DA can generate SQL it's also
completely flexible and you don't have to use the auto-generated SQL. On
the server there's a BusinessProcessor class that handles
inserts/updates/deletes that gets autogenerated. You don't need to use
the autogenerated one - you can specify one yourself with one or more of
your own handlers for the inserts/updates/deletes. These can include SPs
no problem. You can pre-process and post-process the deltas etc -
complete flexibility. It's fair to say that it's the flexibility that
can lead to a steep learning curve, but out of the box you can get going
pretty quickly.

Cheers, Bob

Steve,

<< Thanks for that.  I'll have to investigate further as I'm using stored
procedures extensively with ElevateDB.  What initially attracted me to RO is
ROZeroConf.  I like the idea of a client app being able to find the server
app, although I have managed to implement something "similar" using IP
multicasting.  ROZeroConf sounds a lot more powerful. >>

FYI, I'm really starting to consider extending EDB to support full-blown web
access, ala using a store (or stores) for static content/images and EDB
external modules for callable procedures.  It's not that much of a stretch,
especially since EDB already has a built-in web server (not activated).

The main thing is getting the EDB Server ported to the Linux environment.
Looks like I'm going to definitely have to consider hiring someone after EWB
is done.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim

<< FYI, I'm really starting to consider extending EDB to support full-blown web
access, ala using a store (or stores) for static content/images and EDB
external modules for callable procedures.  It's not that much of a stretch,
especially since EDB already has a built-in web server (not activated).

The main thing is getting the EDB Server ported to the Linux environment.
Looks like I'm going to definitely have to consider hiring someone after EWB
is done. >>

Nice, that would be very, very useful.

Steve

Steve,

<< Nice, that would be very, very useful. >>

Yes, hiring someone would be extremely useful.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Yes, hiring someone would be extremely useful.

Bring Eryk back. That should solve the DBISAM V2 support problem

Roy Lambert

Eryk,

<< Bring Eryk back. That should solve the DBISAM V2 support problem >>

Eryk has moved on to much greener pastures.

--
Tim Young
Elevate Software
www.elevatesoft.com