Database Access

[Kevin Powick]

We're using PgDAC from DevArt (formerly Core Lab).

http://www.devart.com/pgdac

I've always really liked DevArt DACs, but they didn't have one for Postgres until last year.  So, prior to using their pgDAC product, we were using the components from MicroOLAP.

Considering the other databases we're working with, a great deal of consideration is being given to switching to either DevArt's UniDAC components, or the very popular AnyDAC from DA-Soft.

--
Kevin Powick

[Walter]

I haven't been back it a bit....

I have to agree with Kevin's approach - API etc.

The RTC servers I have created were for very specific requirements which needed 3 or 4 functions.

From day of deployment they have been rock solid and never failed.

Walter

[Peter M.]

Walter, thanks again for your feedback. 


BTW, I'm currently working on the connection pool process...
a. Trying to decide whether to use a TList within a Critical Section, or a TThreadList.

b. Trying to decide whether to remove the DBConnection objects from the List using List.Delete and then add back using List.Add (based on archived articles),
   or whether to add an "Available" boolean property to the DBConnection which I can set to False when being used and True when done.
   (The advantage to "Available" is to keep track of the DBConnection objects and make sure they get freed in case of unexpected termination.)


If anyone has any thoughts on either of these items, I'd appreciate it!

Thanks,
-Peter

[Kevin Powick]

Peter,

Check out TObjectQueue of the Contnrs unit.

--
Kevin Powick

[Peter M.]

Kevin, thanks for your feedback.

I had read about the TObjectQueue which can automatically free it's TObjects whenever they are removed from the Queue.
(I'm still leaning towards TThreadList ... only because I want a thread-safe List of object pointers.)

However, I do see an unrelated usage for the TObjectQueue in my app ... so thanks again for the tip.

-Peter

[lionheart]

Kevin,

Currently i am evaluating uniDAC for my next year project with RealthinSDK as the app server. From what i understand on UniDAC, it has advanced pooling mechanim in the TUniconnection component. So do we still need to implement the DB connection pooling ?

[Kevin Powick]

So do we still need to implement the DB connection pooling ?

I don' t know.  I've never used UniDAC.

--
Kevin Powick

[Peter M.]

lionheart,

Questions:
1. What is the maximum number of simultaneous users/connections you will have?
2. Will any of your clients have firewall issues (do they need to communicate via http)?
3. Will the Requests/Results be handling large amounts of data (+100k, +500k, +1M, etc)?
4. Although Kevin is using PgDAC which is made by Devart (they also make UniDAC), what database will you be using?

Thanks,
-Peter

[lionheart]

Kevin,
Thanks for your reply, I was trying my luck that you have converted your app to unidac . I am using the trial version of UniDAC because i am evaluating the components, therefore i have not the source codes to verify the connection pooling implementation.

Peter,
Thanks for your reply, Before i answer your question please allow me share with you that i understand the importance of DB connection pooling in multi-user environment. The reason i am asking the necessity of it is specific to UniDAC (TUniConnection) which has its own pooling mechanism
and i thought Kevin, yrself or other gurus may share your experiences on it perhaps not to use the feature of the component due to it doesnt work well with RTC etc .. maybe..

1. What is the maximum number of simultaneous users/connections you will have?
Somewhere ard 30

2. Will any of your clients have firewall issues (do they need to communicate via http)?
Should not be a problem because i work hand-in-hand with their MIS.

3. Will the Requests/Results be handling large amounts of data (+100k, +500k, +1M, etc)?
This depends on the parameters the clients set. I have DBgrids with some parameters (editboxes/comboboxes etc) for the users to set
which will be sent to the app server and use as query parameters to reduce the resultant dataset. However if the client does not put any parameters, it will be equivalent to returning the whole table ('SELECT column1, column2.. FROM table') which is not encourage but cannot hinder the user from doing so.

4. Although Kevin is using PgDAC which is made by Devart (they also make UniDAC), what database will you be using?
I will be using firebird for this project. The reason I am looking at UniDAC is for standardization (on my side)to meet other/future clients' request to use their choice SQL server.

[Peter M.]

Thanks for your answers.

If you will only have a maximum of 30 simultaneous connections, perhaps you don't need DB Connection pooling...

Out of curiosity, how did you decide on Firebird instead of PostgreSQL?
(I'm asking because I have to make the same decision.)

Thanks,
-Peter

[Kevin Powick]

If you will only have a maximum of 30 simultaneous connections, perhaps you don't need DB Connection pooling...

Although the decision to use connection pooling is driven by factors such as the number of licensed server seats, the number of users,  server load, and usage patterns, I pretty much always implement it in any multi-user server application. Why waste resources and limit your ability to scale when the implementation of connection pooling is pretty easy?

--
Kevin Powick

[lionheart]

Peter M.

Firebird is the preferred choice of the customer. To me it will be the same coding because i have all the SQLs statements at the app server (no store procs etc) and i am quite happy with my testing with unidac so far which makes it quite easy to switch to other SQL server like PostgresSQL etc..

Kevin,
i agree with you on putting dbconnection pool on all multi-user application. What i am testing now is to use the pooling of the TUniConnection of unidac and see what happens next ;P.

This is what i am testing, please feel free to share your thoughts
1. I use jvpluginframework to modularize the application.
2. Place a UniConnection in one of the plugin. Enable the pooling feature of the component.
3. Place a RtcHttpServer in another plugin.
4. When loading the other plugins, Set all the RtcDataServerLink.server to the RtcHttpServer component in plugin (3) and datasets connection to the UniConnection component in plugin (2) (RtcDataServerLink is great in making this happen wih ease, try to do that in datasnap... hell break loose  )
5. .. still in progress... doing Rtcfuncs etc

[D.Tkalcec (RTC)]

If anyone is still searching for a place to start, take a look at the "rtcDB.pas" unit (added in RTC SDK v4.27), which contains a "DelphiDataSetToRTC" function (Server-side, to "pack" TDataSet data into a TRtcDataSet structure - ready for transport to the Client), "TRtcMemDataSet" and "TRtcDataSetMonitor" components (Client-side, for working wih in-memory TDataSet descendants which can be linked to DB-aware components to display TRtcDataSet data received from the Server) and the "TRtcDataSetChanges" class (Server-side, for accessing changes to a DataSet received from a Client). These new components, classes and functions provide basic functionality for working with DB-aware components when using the RTC SDK for communication, either through RTC remote functions or RTC Linkes Objects.

Best Regards,
Danijel Tkalcec

[Ronald van Tour]

Hi Danijel,

A small demo would help to get of the ground

[D.Tkalcec (RTC)]

Would a "Fishfact Demo" be enough, or does it have to be something more complex?

Best Regards,
Danijel Tkalcec