Attila Kovacs you're thinking too much like a Delphi developer. The people who wrote this code didn't seem to know squat about Delphi. The don't even use Actions to manage enabling/disabling menu items and fields, so there's dozens of lines of code that do that for different groups of fields.
I'm looking at code on forms that have 30-80 TADOQuery and TDatasource components on them. Every slightly different query was stuck into its own query component. Some of them are wired to DB-aware controls, even though they don't really treat them like DB-aware controls -- there's one record being manipulated, and the update/save logic takes values from every single DAC and puts it into yet ANOTHER query that's used to update the db table. Over half of the controls on most forms are lookup combos. One form I noticed has three variations of "Boolean" queries that select between "Y/N", "A/B", and "T/F".
Maybe two or three queries have events on them, mainly used to initialize a few fields when a new record is being added. Most of the queries that take parameters pull in one or two fields from a globals unit; very few take local values. I hate dealing with code that looks like it was written in another language and platform, but just happens to be Object Pascal!
Another project here had one form that had over 80 TQuerys on it. Late on a Friday afternoon, a colleague was looking over all of the queries and code and had a huge AHA! moment. I came back Monday and he'd managed to replace something like 45 of the TQuerys and a ton of code with one stored proc that took 5 arguments. He wrote a second stored proc that replaced another 20 TQuerys and a bunch more code.
Attila Kovacs you're thinking too much like a Delphi developer. The people who wrote this code didn't seem to know squat about Delphi. The don't even use Actions to manage enabling/disabling menu items and fields, so there's dozens of lines of code that do that for different groups of fields.
ReplyDeleteI'm looking at code on forms that have 30-80 TADOQuery and TDatasource components on them. Every slightly different query was stuck into its own query component. Some of them are wired to DB-aware controls, even though they don't really treat them like DB-aware controls -- there's one record being manipulated, and the update/save logic takes values from every single DAC and puts it into yet ANOTHER query that's used to update the db table. Over half of the controls on most forms are lookup combos. One form I noticed has three variations of "Boolean" queries that select between "Y/N", "A/B", and "T/F".
Maybe two or three queries have events on them, mainly used to initialize a few fields when a new record is being added. Most of the queries that take parameters pull in one or two fields from a globals unit; very few take local values. I hate dealing with code that looks like it was written in another language and platform, but just happens to be Object Pascal!
Another project here had one form that had over 80 TQuerys on it. Late on a Friday afternoon, a colleague was looking over all of the queries and code and had a huge AHA! moment. I came back Monday and he'd managed to replace something like 45 of the TQuerys and a ton of code with one stored proc that took 5 arguments. He wrote a second stored proc that replaced another 20 TQuerys and a bunch more code.
/sub
ReplyDelete