David Schwartz

I'm constantly seeing little red lines show up in perfectly good code in 10.2.3, even right after a clean compile. It's pretty damn worthless a lot of the time.

I don't think anybody is getting my point. I've seen this problem arise in numerous projects over the past decade that use virtually every DAC and DB server there is. THEY ARE NOT THE PROBLEM. What I have NOT seen is any sort of coherent discussion or approach that anybody took, nor have I seen anything cited anywhere that helps Management get their arms around the REAL problem. As I said at the very beginning, IT'S A GENERAL QUESTION! People keep trying to make it specific to my current situation or this or that component lib. It's NOT! Well, if nobody can address it BROADLY, and instead they can only speak to how to deal with this DAC or that DB, then there shouldn't be much surprize over the fact that Management isn't getting any useful input to justify anything else. Management does not seem to understand the impacts that fundamental architectural differences have going from a traditional Client/Server to a server-based "cloud" solution. And if we as "technical experts" cannot shed light on this issue without bringing up obscure details rooted in what specific DAC or DB is involved, then there's a big disconnect happening and nothing useful being communicated to fill the gap. All I can point to is a bunch of projects I've seen that were supposed to take "only 18 months" and not one of them was even close to functional after 24 months. Meanwhile, migrating the Delphi app would have taking way less than 18 months. But again, the perception on the part of Management has usually been that "the problem is Delphi" where the REAL TRUTH is "the problem is the architectural change that made the current app unfit for the job". Delphi is irrelevant. If all you can do is talk about the DACs -- an inherently Delphi-specific technology -- how in the heck can you convince anybody that the problem is NOT Delphi? Any app written in Visual Studio or any other platform that adheres to a classic Client/Server architecture is going to have the exact same architectural problems. But nobody is talking about THAT! Is anybody starting to get my point now?

Yes, it was. I posted my reply, then realized I wanted to quote the message it was replying to. When you hit the Quote button, it opens a new reply. It's not clear how to copy that into an existing reply. So you end up with a duplicate post and no way to delete one of them. I just don't get the point of a policy that simply causes a lot of needless clutter and additional work for people who are already over-worked (Ie., the moderators/admins)

My question refers to a use-case that's similar to thousands of others like it: suppose you have an app built in, say, D7 that was originally designed as a client/server app, using standard Delphi components available at the time, and it's now exhibiting poor performance after replacing the local file server with a DB server (MS SQL Server, Oracle, MySQL, whatever) because the 243 SQL queries on the 178 forms are all set to do "select * from xxx" in order to populate the controls on the form. So loading up some forms can literally take 10-15 minutes. It's a very general question: how does one usually deal with this? (In my experience, Management usually says, "We're going to rebuild the app in C#/.NET because Delphi clearly can't handle this workload." But I'm asking for a more TECHNICAL explanation that doesn't just throw the baby out with the bathwater and start over from scratch.)

It's a more general question than that. I mean, what do you do with apps that migrated from client/server to DB servers and now they have performance issues because of this? It's not like we can go through and replace every DB control that resembles a list with a VirtualTreeView. Maybe they need to be replaced with something, but surely not all with the same component.

yes, I've got one of these with 7500 elements in it, It takes a couple of minutes to build, and once it's loaded-up, it never changes. So I want to save it to disk or a BLOB in a DB and reload it later instead of having to rebuild it each time. All I need is .SaveToStream and .LoadFromStream. It doesn't need to be human readable; faster is better.

Are the GetIt packages on the ISO distro?

"Free" doesn't equate to "open source". For example, I bet none of the Konopka / Raize stuff is going to be found on any github sites. That doesn't mean it would unreasonable to have a DL page that requires you to long to your back-end (like "Registered User Downloads")

Advocating cutting off one's nose to spite their face seems to be a popular past-time among some Delphi users. If it's not one thing it's another. I've been using 10.2.x for over a year now, and I'm quite happy with it. But it's annoying to see something broken in 10.2.3 that was working fine in earlier versions. GetIt has never occurred to me as well thought out or nicely implemented. It's like a prototype that someone showed to upper management who said, "Great! Ship it!" It has a bug in 10.2.3 that renders it useless. There's no workaround, and it's super-low priority, so who knows when it will ever get fixed (in 10.2.3, anyway). All of these files are free, so this should be regarded as "a NICER way of installing" rather than"the ONLY way". Which means I have to load up a VM from last year with an older version of Delphi on it just to get something off of GetIt for use in 10.2.3.

It doesn't work now. It generates a run-time error. Did you read my original post? I'm getting "invalid type cast". It's in GetIt250.bpl, and apparently others are as well. And there does not seem to be any workaround other than going back to an earlier version.

That seems to only suggest how to install things that have already been downloaded. GetIt launches, but there's nothing displayed. No way to DL anything. Isn't there some way to actually grab the installation files and install them manually?

D10.2.3 does this by default, as Dennis07 says. Rather a PITA for my present needs.

We use a very old version of TFS. I hate it. We're switching over to git, but one of our devs insists on using git like TFS, and he refuses to do any sort of branching. Perhaps the newer versions of TFS support branching. But the only way we have of interacting with TFS is through VS. For git, there are tons of different interfaces, even VS. Delphi's IDE interface with git isn't very flexible.

Since you're just learning, you should try out different options. What will work for a prototype is not likely to scale-up very well if you don't know what you're doing. You need to walk before you run, and while I applaud your questions, you need to just play around and see how everything works. You've said you're using a REST service, then you ask about connecting to the DB with Delphi. The client side won't talk to the DB, the REST endpoint logic will do that. And if you're using an integrated ORM, there's really very little to worry about regardless of what DB you choose -- it becomes almost invisible if it's supported by the ORM.

The built-in FastMM isn't very useful as far as gathering diagnostic info goes. You pretty much need the enhanced version with the debug DLL.

I've never found the status reporting by FastMM to be very useful. It logs a ton of stuff that's all nearly identical and hard to distinguish what varies. I built a tool that does sort of a "cross-tab" on the data (like in Excel) and lets you view the data in a more useful way -- it lists things by object rather than by individual references to unfreed memory blocks. The thing is, most of the references that show up are for down-stream errors that are not related to the root cause. For example, if you fail to free a TStringList that's got a bunch of objects attached, you'll get a bazillion errors on unfreed strings and other crap contained in the stringlist and classes attached to the Objects array, and only one or two hard-to-distinguish references to the stringlist itself. In other situations, it will NEVER show the list responsible for the leaks! However, it does kindly shows you exactly where all of these things were all allocated, but that's often 100% irrelevant -- so you end up on a meaningless wild goose chase. The truth is, 99% of the stuff that FastMM reports is simply NOISE. I just spent 2 hrs the other night trying to track down a group of orphaned objects that I was absolutely certain were being freed. I looked at all of this code, wrote a bunch of tests, stepped through the Free/Destroy code and checked everything I could think of. Finally, I looked at the number of objects being allocated, and then at the number being freed. All of the structures I was looking at that I _thought_ were responsible for the leak showed they were actually freeing up exactly the same number as were being allocated. So I started wondering, "Where else am I allocating things that aren't in these two lists?" Well, it turns out I had a loop that created an object at the top and added it to a list. Then it does some checking, and if it doesn't find anything interesting, it removes the object from the list. At the end, that list's contents were being added to another list where I thought the leaks were coming from. The difference was, the first list was not set to own its objects, while the second list was. This was by design. What I overlooked was the Remove operation in the first list did NOT free the attached objects! Nor did my code. So FastMM generated SEVERAL HUNDRED references to orphaned objects that it found due to 65 objects I removed from a list but forgot to free. And because it was pointing to the orphaned objects, I had no hints as to which list they were from. In actuality, the Remove operation took them OFF of the list, so when FastMM found them, they were just orphaned objects outside of ANY container, located miles away from the last place they were referenced! The only way I was able to track this down was comparing the #allocated objects vs #freed objects on each list, and that led me to one list that allocated more objects than were freed, even though they had been removed from the list. I'm mentioning this because this is probably a very good heuristic to measure right up front that might help track down the source of many leaks way faster than anything else I can think of.

I don't need an executable. It's just that posting the sources here directly take up most of the page and distract from an otherwise useful discussion.

Thanks, I do appreciate this, although a zip file attachment would be a lot easier to work with 😉 That's a LOT of text to scroll through here. I noticed that the DWS project has migrated to BitBucket. Is there anything to be aware of when using it?

@Dany Marmur Thanks! We have DevEx ... what's RTC?

They're scattered across a few hundred source files. It's probably worth taking a look. Do you want to post it here and I can grab it, then you can leave it or delete it later?

some are simple, some are quite complex. The thing is, right now they're embedded in Delphi code on the client side. We want to move them into the server as stored procs, funcs, and views, and then replace the code on the Delphi side with simple calls to those server-side objects, parameterized where needed. (We're preparing to migrate from Oracle to PostgeSQL, and there are tools that can convert server-side assets automatically -- not 100%, but enough to be useful. However, they won't read the Delphi code! So we want to take this opportunity to extract all of this random business logic and other SQL CRUD code from the client side and move it over to the server where it belongs.)

care to elaborate a bit?

I think 10.2.2 broke this, and 10.2.3 didn't fix it. I certainly don't like the idea of having to use 3rd-party addins to fix things that the compiler team broke.