Anders Melander

You don't need to copy data from one FireDAC dataset to a TFDMemTable; All FireDAC datasets are mem-tables and can work in offline/briefcase mode. All you need to do is make sure you fetch all data from the server. Do a FetchAll like it said in the other thread posted.

AFAIK nowadays the ODBC driver is the native driver.

Check ResourceOptions.CmdExecMode; It should not be amAsync. Sorry. You already checked that. If you can, monitor the activity on the SQL Server to see if there is activity on your connection that you can't account for. I still think it's MARS (I've been bitten by that one many times). I can't remember if it can be disabled on the server, but that's one thing to try (just to rule it out).

You are not a serious person, are you? Uselessness is not defined by the existence of some newer - unless, of course, that's your only criterion.

Did you Google the error message? As the error message hints at, it's a concurrency issue; Your application attempted to call the DB server with a request while the connection was busy with a prior request. This happens if you are executing statements asynchronously. If you have MARS enabled I believe that can also cause the problem. Disable it in your connection string.

2022? It's useless!

Your code makes no sense. Instead of: value2 := random(500) + 1; while value2 < 251 do value2 := random(500) + 1; why don't you just: // Values from 251 to 500 value2 := 251 + random(250);

I have a client who wants to use DWScript to do structural load analysis of large models (thousands to millions of nodes). Since DWScript compiles to an AST (Abstract Syntax Tree) and then executes the objects in that tree, he was a bit concerned about performance. He had tried various other scripting systems and they were just too slow. So we did some benchmarking of a sequence of typical calculations in Delphi vs DWScript. As expected the Delphi compiled code was about 4 times faster than DWScript. The client thought that that was acceptable but I decided to try out the DWScript jitter anyway... As it turns out there might just be something to David's complaints about Delphi's math performance 😉 because with the jitter enabled DWScript was now more than twice as fast as the native Delphi code. Also, Delphi 64-bit was about 25% slower than 32-bit and 64-bit "optimized" was slower than "unoptimized". Not to take anything away from Eric Grange's amazing work on DWScript, but I would be embarrassed if my native code compiler was outperformed by a scripting system.

This place isn't representative. Most developers don't participate in communities and don't even know they exist. I've worked at a lot of different places and with a lot of different developers in my career and I think I've only ever met one other developer IRL that participated in communities. Not that I can see. My experience with Lazarus/FPC is limited to using it to make some open-source projects FPC compatible but from my POW they are constantly playing catch up with Delphi. And I think Lazarus sucks as an IDE.

Yes, you probably need to use a custom renderer to get control over the formats used. https://github.com/microsoft/Windows-universal-samples/blob/main/Samples/DWriteColorGlyph/cpp/CustomTextRenderer.cpp

Probably because of its size. Most Noto fonts are huuuge. Noto Color Emoji contains both COLR and SVG data. The COLR data is ~1Mb while the SVG data is ~18Mb... I'm not sure what you are saying here. Microsoft is the primary author of the COLR format and DirectWrite supports all the common color glyph formats: https://learn.microsoft.com/en-us/windows/win32/directwrite/color-fonts However, the client has to specify what format to use during Shaping and if the client asks for SVG glyphs then that is what it will use. https://learn.microsoft.com/en-us/windows/win32/api/dcommon/ne-dcommon-dwrite_glyph_image_formats You can try subsetting the font to exclude the SVG data and see if that makes a difference (apart from the 18 Mb data saved 🙂)

SVG color fonts are probably slow. All the other color font types (COLR, SBIX, CBDT) should perform more or less on par with regular OpenType fonts.

Beware of unqualified statements involving always and never. Unless the advice is to never put pineapple on pizza. That one is just a fundamental law of nature. As you've discovered it depends on the type of the variable. Local variables are declared on the stack and such doesn't involve the heap (i.e. the memory manager). Allocating a variable on the stack is basically free of cost. However, managed types need initialization and that initialization can be costly. TSearchRec contains a string and is therefore a managed type (i.e. slow). Integer is not a managed type (i.e. fast). Additionally, managed types are wrapped in an implicit try..finally block to ensure that they're also finalized. The help probably has more info on this. If you want to limit the scope just put a begin...end around the whole thing: begin var FileRec : TSearchRec; while not StopSearch do begin ... GetData (FileRec); UseData; ... end; end; Apart from that, in this particular case, you are touching the file system so the performance of inside vs outside will be dwarfed by that. ...and so the lesson here is: You don't get more useful insight by asking first.

What? Are you saying that this wasn't a good idea?

And how many articles have there been on TForm, TStringList, or TBitmap? Blog posts are just them doing marketing. It's hardly an indication of anything other than how much they want you to buy the product.

That's nonsense; RAD Server is not a replacement for DataSnap and DataSnap is not being discontinued. Actually, IMO it is more likely that RAD Server will be discontinued before DataSnap is.

I miss it every single time I need to install/update. Apparently, there are no UXers left at Embarcadero. Left-aligning the button would likely solve the problem but ideally, it should not be placed on the EULA page where one habitually just clicks through.

Looks interesting but then I went to the SonarQube site to see what their commercial terms were like and... Of course, given that they don't even list prices and that I had to Google for them, I guessed that much. OpenSource only then, I guess.

Why do you say that? My guess is that you've been googling and once again have found some information that only applies to a specific product's implementation of WebDAV and once again haven't bothered to try to understand the context of the information. Maybe read the WebDAV specification instead.

It's a private repository... and why don't you migrate it to 64-bit yourself?

AFAIK the zlib library that TZipFile wraps does not support LZMA compression. If you google for "delphi lzma" there's plenty of other solutions.

It makes better sense when you've read the documentation... https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow And as is usually the case with things like this, Raymond Chen has words: https://devblogs.microsoft.com/oldnewthing/20090220-00/?p=19083

Sigh. Did you actually read the posts you highlighted? None of them are relevant to you. You do not need Indy to support it. You just need to be able to handle HTTP requests on the server and send requests from the client. Your server implementation will be completely custom to your application (like every other WebDAV server (which is also why you won't find a standard WebDAV "component" on any platform)) and since you will not be using a standard WebDAV client application, your client implementation might as well also be completely custom. If there's an Indu client component that can do what you want then sure, use that. WebDAV is a very simple protocol and would be easy to implement using standard HTTP components. There's nothing special about those requirements. I would think most WebDAV implementations have similar requirements. User authentication is handled in another layer (pretty standard http layering). The WebDAV layer gets user info from that layer and decides what the user is allowed to access and do. What would a user do with a list of "thousands of files and folders"? This sounds a bit like one of my current clients who as a requirement specified that "the grid must be able to display and scroll through a million rows without any lag"... I mean I could limit the grid to 10,000 rows and nobody would ever notice. Regardless, I don't see why sending a list of "thousands of files and folders" would become a performance problem. Regardless of what solution you go for, it's the same information that is going to be sent over the wire. Anyway, it sounds like you are rubber-ducking a bit here and it would probably be smarter to first figure out what it actually is you want to do before asking about how to do it.

I don't know why you quoted that specific document without specifying the source: https://support.netdocuments.com/s/article/360044231332 It's just some CMS service provider notifying its users that it no longer supports WebDAV. WebDAV isn't going anywhere; It's just a protocol standard.