Leaderboard

I am a systems administrator and with every upgrade there is always risk and someone's system becomes unusable. To avoid some grief here is a pre-check list of the basics from a system level to help put together a back out plan. 1. Full backup via system image As always, data loss is unacceptable and not being able to roll back is unacceptable. Take a system image. 2. Source files - Branch or Backup I plan to branch my projects for the first few days in 11.2 so I have a rollback. Anything that is not in source control should obviously get a snapshot via zip or backup software. 3. Registry export reg export HKCU\SOFTWARE\Embarcadero\BDS\22.0 Pre_11_2_BkUp.reg Always have a backup, and read the release notes / known issues before you upgrade. No need for good luck with this upgrade, you have a back-out plan !

Don't use json. I usually send via MultipartFormData, encoded in WebP with 80% quality, as it is practically identical to the original. See attached the original png image of 2292 KB and the WebP with 80% quality resulting in 61 KB. photo.webp

Would suggest using the Microsoft OLE DB Driver for SQL Server - OLE DB Driver for SQL Server | Microsoft Docs instead of ODBC. Without seeing your code it is just guessing why it is slow. Certainly a large difference between local and over the network suggests your code isn't using ArrayDML with a large enough batch size or any batch size at all.

Would the System.IOUtils TDirectory.Delete() work for you ? It has the "Recursive" parameter option. class procedure TDirectory.Delete(const Path: string; const Recursive: Boolean); var PostCallback: TDirectoryWalkProc; begin CheckDeleteParameters(Path, Recursive); if Recursive then begin PostCallback := function (const Path: string; const FileInfo: TSearchRec): Boolean var CompletePath: string; begin Result := True; if (FileInfo.Name <> TPath.FCParentDir) and (FileInfo.Name <> TPath.FCCurrentDir) then begin CompletePath := TPath.DoCombine(Path, FileInfo.Name, False); // clear read-only, system and hidden attributes that can compromise // the deletion {$IFDEF MSWINDOWS} FileSetAttr(CompletePath, System.SysUtils.faNormal); {$ENDIF MSWINDOWS} case FileInfo.Attr and System.SysUtils.faDirectory of System.SysUtils.faDirectory: // remove empty directories RemoveDir(CompletePath); 0: // remove files DeleteFile(CompletePath); end; end; end; // delete all the files and subdirectories WalkThroughDirectory(Path, '*', nil, PostCallback, Recursive); // DO NOT LOCALIZE end; // delete the directory itself {$IFDEF MSWINDOWS} FileSetAttr(Path, System.SysUtils.faNormal); {$ENDIF} RemoveDir(Path); end; BTW: It has also a CreateDirectory, which uses ForceDirectories(FullPath); and seems a little bit more reliable class procedure TDirectory.CreateDirectory(const Path: string); var FullPath: string; begin FullPath := TPath.DoGetFullPath(Path); CheckCreateDirectoryParameters(FullPath); ForceDirectories(FullPath); end;

Fellow forum members educated me of feature I did not know existed, or I knew, but I never used it this way. I've attached pdf-file for the info. Thanks all helping to get the call count, this is pretty cool. Get call count with Delphi Debugger.pdf

I just noticed that if the breakpoint has a condition, the pass count reflects the number of times the condition was true. That's actually pretty nice. Now if only one line could have multiple breakpoints with different conditions... 😇 PS: Fun fact: If you kill the process with [Ctrl]+[F2] rather than letting it terminate gracefully, the IDE will still show the last pass count for a breakpoint.

Add a breakpoint at the proper source line and open the context menu on that breakpoint. Set the Pass count to some high value. For more info see the docs: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Add_Source_Breakpoint

No, but Repaint() is. In any case, depending on what the rest of your loop is doing, it may be worthwhile to move the logic into a worker thread, and then have that post updates to the UI thread when it wants to display something.

Have you found the solution? I seem to have found the solution. I created the pythonengine and pythonmodule etc in a background thread procedure TQuoteThread._CreatePython(TheNil: TObject); begin RichEdit1 := TMemo.Create(nil); PythonGUIInputOutput := TPythonGUIInputOutput.Create(nil); PythonGUIInputOutput.UnicodeIO := true; PythonGUIInputOutput.Output := RichEdit1; modDBFireDac := TPythonModule.Create(nil); modDBFireDac.OnInitialization := modDBFireDacInitialization; modDBFireDac.ModuleName := 'DBFireDac'; PyDelphiWrapper := TPyDelphiWrapper.Create(nil); PythonEngine := TPythonEngine.Create(nil); // 4.17 PythonEngine.IO := PythonGUIInputOutput; modDBFireDac.Engine := PythonEngine; PyDelphiWrapper.Engine := PythonEngine; PythonEngine.LoadDll; pyObj := PyDelphiWrapper.Wrap(self); // 4.15 with GetPythonEngine do begin // Define a new variable "T" in the DB module //4.37 modDBFireDac.SetVar('MainForm', pyObj); modDBFireDac.SetVar('BackgroundThread', pyObj); //4.37 Py_XDecRef(pyObj); // Excecute the script ExecStrings(aLines); end; end; Then in the python script, it assigned the delphi thread to a python object delphithread = DBFireDac.BackgroundThread When I need to pass output to Delphi, from within python script, I simply call the delphi thread method delphithread.AddLine(text) In Delphi, the Delphi Thread method use TThread.ForceQueue to call a Form Method which add the output text to a TStringList procedure TQuoteThread.AddLine(TheLine: String); var aObj: TStringObj; begin if (TheLine <> '') and Assigned(UIEvent_PrintLine) then begin TThread.ForceQueue(nil, procedure begin aObj := TStringObj.CreateWith(TheLine); UIEvent_PrintLine(aObj); FreeAndNil(aObj); end, 1); end; end;