Uwe Raabe

What Delphi version and Windows version? Is it constantly appearing or sporadically? Any non-standard settings or IDE plugins? (except MMX of course) Does it happen with a clean installation?

I am not able to reproduce this here.

Make a binary search: Remove all of them to see if the problem is related to these packages in the first place. Then install half of them and see if the problem comes back. Continue to divide the offending part until you found the culprit. BTW, how many cores has your system?

"DOPE" for Delphi Organizer for Packaged Externals

That error is not related to MMX, but somehow to the docked forms. In contrast to your case I haven't been able to reproduce it with standard IDE forms, though. The relation to the .dst files doesn't actually surprise me.

I have seen similar issues with MMX after a debugging session. Does it help to switch layouts or unpin and hide/show the palette window? I guess that slipped in with reducing the flicker of the IDE.

It is "Strg+" One can get these translations when Delphi is installed with the German language pack (similar for French and Japanese).

It looks like you are in installing a 10.3 package into 10.2. The 10.3 package references rtl260, which makes the Tokyo IDE crash. Usually these packages should have a compiler version specific suffix (like 250 or 260), but it seems the GR32 packages are missing this LIBSUFFIX setting.

indices = plural of index; also called indexes

Delphi comes with a MigrationTool for this. I haven't used it myself, though.

Even a Delphi Update requires uninstalling first, which usually is handled by the setup itself (at least for the web-installer). I have done this several times and each time my Delphi environment kept intact.

Re-Installing Delphi doesn't mean you have to install all components. If you opt to keep the registry entries (and obviously don't remove any components yourself), you should have all your components available after Delphi Enterprise is installed again.

The query mock is your TFDMemTable, that is mocking the original query for the unit tests.

If the goal is to have a close match to the real case, it might be worth to create the query mock indices the same as the database ones.

This sources were initially provided in this thread: 64 bit compiler running out of memory The current thread is more or less a follow up of the former. There are plans to put the project on GutHub when I find some time.

There simply is none - yet. As I provided the sources feel free to tweak it to your needs. This is already covered by the Compressed = 0 option in the config file.

Yeah, that seems like a god idea.

Setting the Compressed option in the config file to 0 places each unit in a separate line. The grouping and order of the groups can be controlled with the GroupNames option in the config file. Leaving that empty will preserve the original order. Inside a group the original order is preserved, too.

Good point!

No, the zip only contains the source. I have attached another one with a compiled exe and a cfg file. UsesCleaner.zip

You may get better results when you provide a proper UsesCleaner.cfg file. See my comment here for details: 64 bit compiler running out of memory

Perhaps you are missing a proper config file (default is UsesCleaner.cfg next to the exe). If there is none, the program will use the default settings which are - well, somewhat special: procedure TSourceFileUsesClauseFormatter.InitSettings; begin UsesHelper.UnitAliases := 'WinTypes=Winapi.Windows;WinProcs=Winapi.Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE;'; UsesHelper.UnitScopeNames := 'Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;System;Xml;Data;Datasnap;Web;Soap;Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell'; UsesHelper.SearchPath := 'c:\Program Files (x86)\Embarcadero\Studio\19.0\lib\win32\release'; UsesHelper.GroupNames := '<UnitScopeNames>'; end; In your case, the SearchPath may be the culprit, which may cause the standard units not to be found. A decent config file can look like this (with an adjusted SearchPath entry of course): [Settings] Indentation=2 Compressed=0 MaxLineLength=130 SearchPath=c:\program files (x86)\embarcadero\studio\21.0\lib\Win32\release; UnitAliases=WinTypes=Winapi.Windows;WinProcs=Winapi.Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE; UnitScopeNames=Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;System;Xml;Data;Datasnap;Bde;Web;Soap;Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell GroupNames=@DelphiOTA;Winapi;System.Win;System;Data;FireDAC;Vcl [Groups] DelphiOTA=ToolsAPI;DesignIntf;DesignEditors

Perhaps this may help a bit: UsesCleanerSource.zip

Does it work when you replace the SetRange call with a sequence like this? SetRangeStart; FieldByName('Exact').AsInteger := -6; SetRangeEnd; FieldByName(Exact').AsInteger := 16; ApplyRange;

The order by is not necessary, but an local index on the field in question is. If the problem lies in FireDAC it should be possible to create a small test program with a TFDMemTable.