bobD

Certainly. but the details of that would depend entirely on the database schema, including knowledge of the table structures, the view you're referring to, and any/all other relevant complications (such as db triggers and rights of the the user connection.) One of the first questions that occurs to me is "what do you mean by an 'invoice'? My tendency is to regard invoices as simply statements (ie, point-in-time reports) of the financial status of an account. The 'real' underlying objects being reported on are the account and its billable orders. Credits applied to an account would normally be applied to each billable order amount in sequence from oldest to newest until the credit was exhausted, w/ any amount left over then becoming a positive balance (credit) on the account. A superseding invoice or refund might then be generated to reflect the new account status. bobD

Context latest Delphi 10.4.1, Arch and Interbase 2020. Windows 10. FireDac. Local home network, both cat-6 wired (desktops) and wifi (laptops) The laptops are much slower on connecting--enough to be annoying--so I'm thinking about using primarily either ToGo or a local IB server. The data has a high-use but low volatility, so coordinating between the local and main servers will be relatively trivial. Is there a good sample app for setting up an embedded or local IB delphi app? I assume I have to include different files. The one briefcase model I found used a server and local flat files. Thanks for any help or links. bobD

Don't know if I provided too much context or not enough. I've got a pretty good idea what's slowing down the wifi, but not really interested in that, because (1) the unit router actually belongs to the apartment building. It's single band 2.4, but more than adequate for most purposes, and more importantly (2) this is mostly just an excuse to learn more about IB and FireDAC. I worked professionally against SQLServer for well over a decade, mostly dbGo, but also ODBC and (many years ago} BDE. But I never had the occasion to write a briefcase app: all strictly C/S. Since I'm retired now I have time to learn IB and FireDAC. What I didn't see in the Rad Studio samples is a pair of clear examples of the difference between setting up a Delphi FireDAC app to run IB embedded vs IB desktop. Is that a matter of FireDAC connection settings? Specific files in the connection datamodule uses clause? Some specific FD physical layer support component? I can easily set up a local IB connection, but since my dev machines have a local IB server running, I can't say for sure I know whether it's embedded vs desktop. I want to get the connection options completely sussed before moving into all the other new (to me) IB/FD goodies bobD

From the description of where you are ("click on button perform queries and display results"), this is an immense topic. Probably the classic intro to object oriented design is Object-Oriented Software Construction by Bertrand Meyer For a simpler approach (and with the benefit of being written for Delphi), try NIck Hodges' books on coding in Delphi. They're straightforward and very approachable. Bit more detail in Hands-On Design Patterns with Delphi by Primoz Gabrijelcic These will get you started with OO thinking--the prerequisite to architectural layering. In the mean time, how to refactor your current code to make it more maintainable? I'd suggest trying this: New rule: no data access objects on forms. Those belong in data modules. Organize the modules into groups of logically related queries. That will start to separate out your code by 'topic of concern' so you can start grouping logically related code. bobD

The blue dots indicate that code was generated for that line, not that that code is known to be called. It's 'used' only in the sense that the compiler used it. For a public method, knowing for sure that a public method is not used would entail inspecting the implementation code for all other units in the project; the class might appear in an implementation uses clause, so just reading all the interface sections wouldn't do it.. So Delphi would have to be rearchitected as a multi-pass compiler to optimize the code at that level, inspecting and cataloging the entire code base before compiling anything. Said more simply: while you can know what's used and what not, the compiler has no way to know that at the time it's compiling the unit.

I appreciate the fact that Delphi has solved the structural issues. Now, recommendations for a vendor that provides a high-dpi capable library of replacements for the classic (Delphi 7 era) icon files? I have an older app I'm updating, and need icons that will work for my menu items and speedbuttons. Thanks, bobD

What Remy's approach does is accomplish OO 'separation of concerns'--decomposing all the logic of 'Save' into those component parts which might be subject to independent change and testing. So while a bit more code initially, it's much more maintainable and reusable. The pattern is equally applicable whether the storage mechanism is a TList or a zillion record database--only the technical details of how find, inset, and update work need be addressed. The higher level application logic is stable because all the underlying technical details have been isolated out. bobD