On Tuesday, October 21, 2008 10:26 AM Fastream Technologies wrote > Către: Delphi-Talk Discussion List > Subiect: Best async ADO/ODBC component for generic DB access? > > Hello, > > I am not very experienced in DB coding--need help! I need to use async > db > connections as they will co-exist on a single thread concurrently. DBs > should be supported are DB2, MySQL, Oracle, and Yukon. Will be coding > in > Delphi/BCB2009. I need to be able to pause DB connections. Please > advise.
If a async DB connection-component exists it would NOT be a TDataSet descendent as everything around TDataSet expects call to be synchronous. (Ex: If I call Open I expect the DataSet to be Open when my call returns. If I call "Next" I expect to be on the next line OR I expect the EOF to be turned True). The component not being an TDataSet descendent would make it an highly specialized component that's good for nothing but async DB stuff and can't be linked to data-aware controls. Because of all those raisons I doubt such a component exists! And if it does exist, I doubt it would provide the broad range of interconnect compatibility you're requesting. Why don't you make your own async component, based on standard TDataSet descendents and threads? I once needed behavior similar to what may be called "async". This was in a VoIP related application, as close to real-time as a Delphi application may get. I had a need to log things into a database while my application handled VoIP calls. Given the nature of VoIP I didn't want to risk interrupting calls to do an INSERT to the database, so I devised a simple plan: Make every kind of request to the database an TDbCommand object; Make a list of those objects; Have a thread that loops forever, peeking one command at a time from the list and executing it. It never crossed my mind to look for a "async" component set that works with my favorite database (Firebird) because I was able to set this working with a separate thread very quickly! If you do want to go with my idea (threads, lists and command-objects), just remember to protect the list with a TCriticalSection and use an TEvent that gets set when a new command gets put into the list. Make the thread wait on the TEvent, not "sleep" doing nothing. This way you're not wasting CPU time looping for nothing, and you'll be VERY quick to react to any new command that gets put into the list (no need for the sleep command to time-out). -- Cosmin Prund __________________________________________________ Delphi-Talk mailing list -> [email protected] http://lists.elists.org/cgi-bin/mailman/listinfo/delphi-talk
