I have a DB-related question that might seem rather naive, so bear with me. I'm working on a client-server app that's got several dozen forms that have been touched by numerous developers over time. We're currently using D2007.
I have a DB-related question that might seem rather naive, so bear with me. I'm working on a client-server app that's got several dozen forms that have been touched by numerous developers over time. We're currently using D2007.
Most of the forms work on one table (many different tables, but just one at a time), either adding or modifying one record at a time. (It's mostly a huge master/detail list where you select a client and there are several dozen forms that are used to collect and update their status in various areas.)
There are tons of lookup-comboboxes on most forms. So a given form will have a TADOQuery for the main form, and a bunch that are used with the lookup combos. It's 100% TADOQuerys (as opposed to any TADOTables).
Most of the forms are what I've seen in the past, where there's a query that does a SELECT to populate DB-aware controls. When the user says to Save the form, an INSERT or UPDATE statement is composed and run.
But I just found one form written by a relatively novice Delphi dev that treats the TADOQuery like a table. It does a SELECT * to populate a DBGrid; the user double-clicks a row and another form opens up with all of the DB fields populated with the current record's data. They can then select from several actions at the top of the form by clicking buttons like Add or Update.
This then triggers a call to qry.Insert or qry.Edit. When they click the Save button, it triggers a call to qry.Post. The Cancel button triggers a qry.Cancel.
This approach treats the TADOQuery the same as if it's a TADOTable. I've actually never seen this before in a Delphi app! It's as if the TxxTable has a query hidden behind it that's just a SELECT * and other than that they're the same.
Is this considered normal behavior for TxxQuery components? Can you simply change the state to .Edit or .Insert and then .Post the results like with a TxxTable, without having to compose a SQL INSERT or UPDATE statement first?
This particular form has more controls on it than most, yet it's one of the shortest forms (SLOC-wise) in the app, mostly because it's using .Edit, .Insert, and .Post on the TxxQuery component rather than dealing with them separately. (I'm amazed at the gyrations some devs have implemented to deal with this. Some of the forms are incredibly complicated, yet they're all doing pretty much the same basic things.)
Most of the forms work on one table (many different tables, but just one at a time), either adding or modifying one record at a time. (It's mostly a huge master/detail list where you select a client and there are several dozen forms that are used to collect and update their status in various areas.)
There are tons of lookup-comboboxes on most forms. So a given form will have a TADOQuery for the main form, and a bunch that are used with the lookup combos. It's 100% TADOQuerys (as opposed to any TADOTables).
Most of the forms are what I've seen in the past, where there's a query that does a SELECT to populate DB-aware controls. When the user says to Save the form, an INSERT or UPDATE statement is composed and run.
But I just found one form written by a relatively novice Delphi dev that treats the TADOQuery like a table. It does a SELECT * to populate a DBGrid; the user double-clicks a row and another form opens up with all of the DB fields populated with the current record's data. They can then select from several actions at the top of the form by clicking buttons like Add or Update.
This then triggers a call to qry.Insert or qry.Edit. When they click the Save button, it triggers a call to qry.Post. The Cancel button triggers a qry.Cancel.
This approach treats the TADOQuery the same as if it's a TADOTable. I've actually never seen this before in a Delphi app! It's as if the TxxTable has a query hidden behind it that's just a SELECT * and other than that they're the same.
Is this considered normal behavior for TxxQuery components? Can you simply change the state to .Edit or .Insert and then .Post the results like with a TxxTable, without having to compose a SQL INSERT or UPDATE statement first?
This particular form has more controls on it than most, yet it's one of the shortest forms (SLOC-wise) in the app, mostly because it's using .Edit, .Insert, and .Post on the TxxQuery component rather than dealing with them separately. (I'm amazed at the gyrations some devs have implemented to deal with this. Some of the forms are incredibly complicated, yet they're all doing pretty much the same basic things.)
David Schwartz I am always astonished how many developers simply work around this feature and write there INSERT, UPDATE and DELETE statements by hand. Often with error prone and hard to maintain results.
ReplyDeleteDavid Schwartz one brilliant DAC is IBObjects. Unfortunately only for Firebird and Interbase. However; Jasons tutorials digs deep into this stuff and they will teach you about transactions too. IBObjects has a multitude of properties for creating "omnipotent" queries. Any "table" component you stumble across is only for compatibility. Never used a "table" thingy ever.
ReplyDeleteWe always write explicit upsert/delete stored procedures for DB changes. There is no way we would allow direct table operations to a Delphi app connection.
ReplyDelete