David Schwartz

I've had to deal with several variations of that over time. Are there web-hooks in place that call the system to hand over each JSON packet? Or are they just dumped in chunks into a file, accessible by something like FTP? Or do you have to poll a system periodically for new data that has accumulated? 60k records per day isn't that big of a deal. And text is quite easy to compress, especially if there's a limited lexicon involved. Then there's the backing store, where it really depends on the total lifetime of that data, what the half-life of searches is (so you know when you can flush it out to secondary storage with low likelihood of needing the majority of it), and tuning the DB to optimize the queries that come in. In America, certain types of records need to be kept for a legally-defined minimum length of time, like 7 years for corporate and financial records. Most of it isn't ever looked at, but it needs to be kept online and backed-up in case of audits or lawsuits. Just figure out how to compress the crap out of it and stash it away so it's easy to retrieve when needed. The point is, your job is to make sure the recent data is quickly accessible, while the older data is on slower more massive drives but still accessible in a reasonable amount of time. (A subpoena for data might give a month or more to provide it, which should be plenty of time to deal with slower backing stores, or even mag tapes.) Do NOT try to make 100% of it accessible "instantly". The client might have some temporal requirements, but make sure they're reasonable.

Just with Delphi? Do you use other languages with frameworks that provide a cleaner solution? I've only used Delphi. Prior to that I spent most of 15+ years doing embedded systems programming, and they never used DBs for performance reasons. It was pretty low-level C and C++. Frameworks were fairly primitive back then. And there were lots of Delphi apps I worked on that were essentially embedded systems, like stand-alone kiosks, that had content created externally and manually installed -- no DBs were used here either.

Yeah, it often is. What if you're not using DB-aware controls? The OP didn't sound like he was. As I said, the DB-aware controls add a lot of buffering and logic to simplify this. If you just have any random form that's got edits and grids and checkboxes and whatnot on it, and they are NOT DB-aware controls, then what do you do? Like, say, you have a form that displays data returned from an HTTP GET request as a JSON packet that consists of an array of objects, and you want to scroll through the objects as if they're records in a table? I'm genuinely curious. This wide disparity between forms that are used for interacting with DBs that have DB-aware controls on them vs. those that don't -- because you're not using DB -- has always perplexed me with Delphi. I've seen at least a half-dozen different solutions used over the years for the latter case, none of which were particularly elegant. Sometimes I asked the developer why he didn't just use an in-memory table and DB-aware controls, and the excuse was usually that it "added too much overhead to the app". OTOH, there have been numerous situations where I got rid of a bunch of code that did this and replaced it with an in-memory table and DB-aware controls, and the performance actually improved.

Look for the code that causes FileIndex to be set, and then look above it for something that might cause that line to not execute. You're lucky in this case that these are three lines in a row. Sometimes several of these kinds of initializations are set at the top of a proc and the warning isn't issued until much farther down in the body of the proc.

I've generally found it's easier to make one form to ADD a NEW item, and another to VIEW / EDIT the item (either object instances or DB records). But it can depend what's in the form. I've often tried using one for all three, but I often end up with so much code that does one thing for Adding and another for Viewing / Editing that it's just too much of a headache. One way around that is to Insert a new record with default values, then open it in Edit mode. But the problem with that is if the user Cancels out of the form, then you have to be sure to delete the added record. If there's a possibility that someone might issue a query that attempts to access that record, then you'll need a field that maintains a state flag saying it's temporary. If something throws an exception and blows out of the Edit process but doesn't delete the temp item, that can create all sorts of headaches. The areas that cause trouble are fields that are references to chunks of data from elsewhere, fields that contain indices that point to items in a lookup table, along with field validation read errors, among others. To address some of these disparities, adding a new record can require data fields that are flagged as "required" but their data hasn't been selected yet by the user. You have to treat those fields as "required but empty" which is technically an error condition. So you have to put code around that to guard it from throwing an error while tabbing into or out of such a field, because for NEW records it's NOT an error. See my point? Using DB-aware fields figures out a lot of this stuff. But to make it work, you need to add field validations to check this stuff when they click Post on a NEW form. But wait ... those field validation routines now have to figure out if it's Add or View or Edit as well and take appropriate action. So you end up simply shifting that logic from one place to another place. It would be nice to bury it inside of a class, making the objects self-validating, but that's a whole nuther can of worms! Using one form for Adding and another one for Viewing / Editing eliminates all of that selection logic and is a lot easier to maintain. It's also simpler than dealing with inserting a temp object / record first then Editing it because you don't have to deal with deleting the temp if the user cancels the edits or an exception is raised. BTW, the difference between View and Edit is that View sets all of the fields to read-only, and going into Edit mode turns off all of the ones that the user can edit (ie, applies permissions). A copy of the data needs to be kept when you go into Edit mode so you can compare which fields changed and only update them, or restore the field values if they Cancel the Edit after making some changes. Again, DB-Aware controls can do this automatically, but using lists of objects this way may not provide the same logic.

As I said, the trial version is free, but it only runs inside of the IDE. I'll use free code samples to build proof-of-concept prototypes. Not for production code. But production libs that are free to run inside of the IDE are usually quite adequate for proof-of-concept prototypes, and that also means I can usually reuse much of the code I wrote to work with them.

TMS Cloud Pack is the best I know of. (There are a few varieties of it.) There's a free trial that works when running inside of the IDE if it's just for your own use. Only you can place a value on your own time. Far too many programmers undervalue their time and refuse to pay for stuff that costs less than a day's earnings, some less than one hour's earnings. Also, if you're building a solution that's going to put money into your pocket (by selling to clients), then why should someone pay you for something of value if you don't see the value in the work others do? You pay people to prepare food for you; you pay for electricity delivered to your house; you pay for water, sewer, and garbage collection; you pay for clothes that people make; you pay for food that people farm; you pay for music, for movies, for popcorn; you even pay $1 or more for a bottle of water where the bottle costs more than the water inside of it; but you won't pay for software that people write? Let's say it took someone a week to build each of the interfaces in TMS VCL Cloud Pack -- it's probably more than a month, with all of the testing, support, and other stuff they've got invested, none of which you're going to provide by rolling your own -- and you don't think it's worth it to save yourself a month or more of your time by paying $200 USD or so to have a solution ready-to-go in 5 minutes? Do you only earn $200 per month? Is that how LITTLE you value your time -- that you'd "spend" 200 hours of your time in order to "save" $200? That works out to a whopping $1 per hour that you value your programming skills at. This whole notion of "software should be free" baffles the hell out of me. It's like when the CEO of Spotify said recently, "Very little effort goes into making music." Then he raised his subscription rate. Yeah, like that took him a few thousand hours to do. It will actually put a few hundred million dollars into his pocket, while not adding a penny of income to the artists who he's hardly paying for the "very little effort" they put into their artistry. I paid for a college degree in Math and Computer Science. I've spent 40+ years honing my skills, and untold thousands of dollars on tools, hardware, and services. I charge a lot for my time as a software developer, because I believe I deserve it. If someone would rather hire someone from India at $2/hr that's fine by me. You get what you pay for. But I've ALWAYS found it FAR CHEAPER to pay for software that has hundreds if not thousands of hours of work behind it than trying to do it myself from scratch. People PAY ME TO BUILD STUFF FOR THEM! Why would I want to charge them for the time it takes me to re-invent something from scratch that I can buy that's already working, debugged, and production-ready? Spending $200 for a software library that probably has over 1000 hours of work put into it is a SCREAMING DEAL in my mind. (Would it surprise you to learn that I have a TMS ALL-ACCESS PASS license?) BTW, did you write your own Delphi compiler and IDE?

I looked and didn't see this. Thanks for pointing it out.

This looks awesome, long awaited option for Delphi. What Delphi versions does this support?

Whenever I'm tempted to do this, I look very hard at the likelihood that the code I'm dealing with could be moved into a class. If it's only used once, right there, then I may just leave it as-is. But maybe with a bit more abstraction it could be more useful. That said, it's not something I ever think of doing very often because it's a form of encapsulation that's mostly used in classes.

In ChatGPT4, have you tried setting the 'temperature' setting to zero? That's supposedly a setting to moderate how much / little it exercises its own "creativity".

This is exactly why I've chosen to go with TMS WEB Core as it runs in pretty much any web browser. It does not lock you into any particular hardware or OS version. If you need something specific, you can get a cheap machine and use it to build a REST service that the web app can call directly, or indirectly through your app's main service. There's also Crossover, which is a WINE-based containerized solution for running a Windows app in other environments that looks and runs as a native app. It's ok for one-offs, but publishers will need to see if its cost justifies the results.

There's also the problem that XCode upgrades may be required that cannot be installed without upgrading the OS. I stopped upgrading my MacOS a while back b/c it seemed like each time it would lock me out of apps that cost me a lot to update themselves to continue using -- if that was even an option. I have a 2014 Mac MIni running Mojave b/c there are several 32-bit apps that I use but can't update, and the next OS doesn't support any 32-bit apps. I have another one (2018) that's running Catalina and I won't update it either b/c of other things that break and will be expensive to update -- no free updates for these things. This is the machine I use to do my Delphi work on, inside of a VirtualBox VM, and now I can't even upgrade that to the latest version, although they seem to be supporting older versions pretty well. And with the switch to M-series chips, there's a BUNCH of apps I can no longer upgrade b/c they ALL require the latest version of the OS to run. XCode updates all seem to be tied to a specific version of the OS, and they don't maintain backward compatibility for older versions when they add new features to it. Which is why I'm mainly interested in working with TMS WEB Core to build web apps that run inside of web browsers and are not dependent on hardware or OS issues.

That looks pretty slick.

Aside from that, did you get anything from reading the post? (I don't have a compiler in my head, and I figured if I didn't show the declarations then someone would ding me on that.)