ioan

7, the most holy number!

Try something like this: var s: TStream; begin s := TFileStream.Create('soundfile.mp3', fmCreate); try IdHttp1.Get(your_file_url, s); finally s.Free; end; end;

I don't buy it, I don't think this is just hardware failure. My conspiracy theory is that it started with hardware failure and then they realized that the backup didn't backup for 20 years. No matter what hardware failure you have, it doesn't take two weeks to get it back up and running.

You need to make the names match: procedure TfrmDatabaseTutorial.ShowSelectedResults(); Selected not Select

For Enterprise and I just got a quote for $1199 for a year.

TClientDataSet 😉

I have a situation where one server is responsible for hosting several thousands of files, and multiple other servers require access to these files. These servers may have hundreds of concurrent threads accessing, adding, or deleting files on the shared drive. I have been using a windows shared directory to facilitate this access, but I have experienced issues where the shared directory becomes unresponsive, possibly due to too many simultaneous connections. What is the best solution for this scenario? Thanks!

You could use a thread, something like this: type TMyThread = class(TThread) private FRet: string; protected procedure Execute; override; published property Ret: string read FRet; end; TForm5 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } procedure HandleThreadTerminate(Sender: TObject); end; var Form5: TForm5; implementation {$R *.dfm} procedure TForm5.Button1Click(Sender: TObject); var Thread: TMyThread; begin Thread := TMyThread.Create(true); Thread.FreeOnTerminate := true; Thread.OnTerminate := HandleThreadTerminate; Thread.Start; end; procedure TForm5.HandleThreadTerminate(Sender: TObject); begin caption := TMyThread(Sender).Ret; end; { TMyThread } procedure TMyThread.Execute; begin if not clientclass.connected then begin FRet :=''; exit; end; clientclass.msgvalid:=false; idTCPClient.IOHandler.WriteLn(msg); while (not Terminated) and (not clientclass.msgvalid) do begin FRet:=clientclass.msgfromserver; TThread.Sleep(0); end; end;

I started from scratch (had in plan to trim some fat anyway) and now I'm accessing the database directly from the TThread, inspired by the example from Embarcadero: https://docwiki.embarcadero.com/RADStudio/Sydney/en/Multithreading_(FireDAC) The service now works very well, no more access violations. I wish I had the time and patience to actually find exactly what exactly caused the problem, but the problem only appeared in production and I was pressed to fix it fast so I pretty much made it from scratch.

The stack trace I posted is the only thing I get when this access violation occurs. Usually when there is an exception, I get more detailed stack trace, but with this problem, that's the only thing I get.

I tried madExcept several years ago and I couldn't get it to work right in a service, so I ended up using JCL Debug, which works fine. I'll probably have to look into it again.

TOutThread is the main thread that starts lots of worker threads. The problem is in the worker threads. The only global variables I'm using are some strings that I initialize at the application start (before any threads are running) with the initial paths and the worker only read the values. All the other components are standard Delphi firedac database access.

I'll try but I'm not sure if it makes any difference. The code in TThread.Create where the datamodule is created is executed in the main thread.

I have a multithreaded service that creates a TDataModule for each thread. The DataModule has the logic for some light work on a firebird database. My service runs, depending of the hour of the day, between 0 and 300 consecutive threads and about 50-70 thousand total threads in a day. Some threads can be alive for an hour or more, some for few seconds. Most of the time the threads are just idle, waiting for a file on disk (each thread waits for a file with a specific name, no two threads try to read the same file). There are no memory leaks in the service, if I run the service as an application for a whole day in production with the ReportMemoryLeaksOnShutdown := true; and there are no leaks reported. There are no threads that remain hanging, after a certain while, they'll terminate automatically if they are alive for too long (a timeout value depending of what the job is). The problem is that after a random amount of time of running, the thread creation fails at with Access Violation DataModule := TDataModuleMain.Create(nil); and when this starts, no more threads can be created, all of them fail at the same line, the line above. The TThread.Create is as follows: constructor TPFXIncomingMessage.Create; begin inherited Create(true); FreeOnTerminate := true; DataModule := TDataModuleMain.Create(nil); FIsRecovered := false; end; Here is the call stack: EAccessViolation: Access violation at address 0000000000921298 in module 'pfxout.exe'. Read of address FFFFFFFFFFFFFFFF ---------------------------- [0000000000F1EB51] JclDebug.TJclStackInfoList.Create + $151 [0000000000F1E698] JclDebug.JclCreateStackList + $48 [0000000000F1E5A6] JclDebug.DoExceptionStackTrace + $76 [0000000000F20BA6] JclDebug.DoExceptNotify + $86 [0000000000F116C5] JclHookExcept.TNotifierItem.DoNotify + $35 [0000000000F1190B] JclHookExcept.DoExceptNotify + $BB [0000000000F11A65] JclHookExcept.HookedRaiseException + $75 [00000000008F21D3] System.@RaiseAtExcept + $103 [00000000008F2238] System.@RaiseAgain + $38 [00000000015FC969] threaddoit.TPFXIncomingMessage.Create (Line 59, "threaddoit.pas" + 5) + $42 [00000000015FFC76] outthread.TOutThread.ProcessRecRequest (Line 182, "outthread.pas" + 15) + $E [00000000015FF4CB] outthread.TOutThread.Execute (Line 88, "outthread.pas" + 6) + $0 [0000000000A1A1E3] System.Classes.ThreadProc + $43 [00000000008F2DAD] System.ThreadWrapper + $3D [00007FF95AA713D2] BaseThreadInitThunk + $22 [00007FF95C455504] RtlUserThreadStart + $34 The service is compiled for 64 bits. Before I start modifying everything, trying to fix a problem that I have no idea where it comes from, before trying to rewrite a bunch of code that should work and has no memory leaks, my question is: Are there some kind of rules that I don't know about on creating and freeing so many DataModules? I'm asking this because I had the same problem with a RemObjects SOAP service and the answer I got on the remobjects forum was: it is failed at creating _Impl forms. it is weird error and something is happened in delphi’s standard library Any ideas or advice? Thanks.

I understand that, but what if I want to have some other field with the characters masked, would Chrome automatically assume that any masked field is a password field and fill in my password? I think the decision of Chrome developers to ignore "autocomplete="off" is kind of dumb. I hope they'll respect autocomplete="new-password" and not ignore it in a future version.