Stano

Check out IDE Style. That was my case.

OT: I'm no expert on spilled tea. But Your demo is not in Japanese or Korean. In my opinion, it's a random cluster of some characters. No specific language.

MyTable.Fieldbyname('MyField').IsNull

I'm moving on from Delphi.cz As a temporary solution, the LSP from the previous update was published, which does not have some features from D11.2, but works better with some - https://altd.embarcadero.com/releases/studio/22.0/DelphiLSP_11_1.zip

I paid support for one reason only. Hopefully I'll get a patch that fixes the underlying LSP issues At their rate of repairs for two years to be sure

Have the right DataSet. Use Query and there you go Distinct Where Order By - Check it "manually"

Record locking is one of the reasons why many do not use "DBEdit" type components. You definitely didn't want to read that. It leads me to think of using TMemo. Unfortunately, I can't think of a proper way to resolve the conflicting record access situation. It would have to be server side. Maybe someone knows. I personally use Firebird and it does not use record locking in normal mode. OT: in that case, how do you handle a situation where someone starts editing a recording and goes to lunch? Will you shut down all users for that time?

In other words: there are problems with small projects that do not appear with large projects. This applies to LSPs. I don't know if this includes your case.

You probably confirm what I wrote today. Big project - no problems. A small project - there are problems. Emb I know about it. He doesn't know why. Apparently, they would need some small project where they could study it. I don't have one. But problems do.

I have no information. It mainly revolved around LSP. Generally.

It is said that big problems appear in small projects, which are not present in large projects. EMB knows about it. They don't know why. I have a small project. Sometimes I even cry.

Golden socialism. It was almost stable there Irony of course.

Kinda OT As a lay amateur, I am puzzled by the fact that there are several files in one BLOB. Too much. I would save each file separately from the very beginning. I was already taught that with modern DBs the number of records in the table is not a problem. But I don't know your program, nor its philosophy and function.

Jednoduchými slovami. Ak chceš vytvoriť nový prázdny formulár, tak použi príspevok od FPiette. Ak nejaký existujúci tak CardForm := TMyForm.Create(Self);

How can you create something that is nil? More specifically, cast nil to something.

Sometimes this scenario happens to me: Compile - error Build - no error Compile - no error It will probably be similar in your case.

I think that is a mistake. [Warning]: Include file not found: OBSIDIUM_ENC_START in line 160 col 6 [Warning]: Include file not found: OBSIDIUM_ENC_END in line 196 col 22 [Warning]: Include file not found: OBSIDIUM_ENC_START in line 378 col 8 .... uses ... obsidium, ....

What exactly do you mean by that?

If it's a question for me, then: No, I don't know what you're writing about. That is completely beyond me

I don't know what your table looks like, but: every table "must" have a PK primary key You save the PK in the component that displays the data you only access table entries via PK I consider it the alpha and omega when working with DB

I'd rather wait

It didn't help. Just did I do it right?

That will be difficult with me. My knowledge is close to zero. I don't remember such a notice before - but... Some *.inc files exist. Where should they be for MMX to see them? Or what should I do. It's more of an aesthetic problem. I would like to get rid of him.

The vast majority look like this {$IFNDEF DEBUG} {$I OBSIDIUM_ENC_START} {$ENDIF} inherited; FqryService := TFDFunction.NewQry; FqryService.SQL.Text := obsSecureStringW('SQL Text...'); {$IFNDEF DEBUG} {$I OBSIDIUM_ENC_END} {$ENDIF}

I can't understand the code But is it necessary to create a new TQuery every time? I can't judge. In such cases, I have only one TQuery and I only change its SQL.Text.