Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 11 to 20 of 20 total |
Reporting tool |
Wed, Apr 4 2012 4:27 AM | Permanent Link |
Robert Devine | 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 > |
Wed, Apr 4 2012 5:51 PM | Permanent Link |
Steve Gill | 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 |
Wed, Apr 4 2012 6:40 PM | Permanent Link |
Robert Devine | 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 > |
Wed, Apr 4 2012 8:14 PM | Permanent Link |
Steve Gill | 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 |
Thu, Apr 5 2012 3:39 AM | Permanent Link |
Robert Devine | 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 |
Thu, Apr 5 2012 1:49 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Thu, Apr 5 2012 6:52 PM | Permanent Link |
Steve Gill | 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 |
Fri, Apr 6 2012 1:20 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Steve,
<< Nice, that would be very, very useful. >> Yes, hiring someone would be extremely useful. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Apr 6 2012 1:41 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
>Yes, hiring someone would be extremely useful. Bring Eryk back. That should solve the DBISAM V2 support problem Roy Lambert |
Mon, Apr 9 2012 2:00 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |