Jacek Laskowski

This is not the solution I am looking for, I can save and load a dataset content without such "tricks". I'm interested in ADDING a new lookup field with an ACTIVE dataset.

I have simple table: CREATE TABLE WORKSTATION ( IDWORKSTATION INTEGER, MACHINEID VARCHAR(32) ); I create TFDQuery with simple select SQL: SELECT * FROM WORKSTATION w WHERE W.MACHINEID = :PARAM When I set as param string longer than 32 chars then I get error: "arithmetic exception, numeric overflow, or string truncation" I set StrsTrim2Len option to True: http://docwiki.embarcadero.com/Libraries/Rio/en/FireDAC.Stan.Option.TFDFormatOptions.StrsTrim2Len ...but the error still occurs. How to properly config Firedac to eliminate this problem?

@c0d3r I guess you write to me. Well, you're wrong. The database has declared UTF8 type for text fields. The connection is also made with the parameter UTF8.

Once, in Delphi 10.2, I had an identical problem, the cause of which I could not trace. The problem was that the Options window (menu Tools->Options...) was blocked by an exception. To enter Options I had to use GExperts to deactivate all the experts, restart the IDE, enter Options, set what I needed, reactivate all the experts in GExperts and restart the IDE. I did not know what caused this problem. I haven't had this problem since I migrated to Delphi 10.3... until now. I just installed the Selective Debugging expert 😞 Additionally, I see that in D10.3 this exception does not appear, as it used to, every time, but sometimes. For example, a moment ago I entered the options without any problem. ps. I'm sorry to write about it here, but I don't know where it would be better to report it.

I guess I was in too much of a hurry with this report. I guess that's because I was very annoyed by this mistake before. Now, after restarting the machine, the bug doesn't appear anymore, even though I have already entered the settings several times. If something happens, I will let you know.

FastMM in full debug mode + properly configured .inc file

Maybe it is worthwhile to move the 'crypto' library to a new, separate repository? In a common, large repo it is difficult for anyone to find it

@Dmitry Arefiev Maybe now you can reply to this issue? I still fight with it.

History window: Old MMX 14:

$4000? Really?

Imho Indy is a better option because of its popularity and versatility. And I say this even though I use mORMot myself. But of course it would be good to leave support for newer versions based on System.Net.HttpClient. This means that it is best to pack the REST client into a new class and change its implementation as needed: Indy or System.Net.HttpClient

Maybe it is worth to surround the scope check by conditional directives? By default, the scope check would be enabled in debug and release, and for demanding users it would be possible to achieve maximum performance at the expense of a slightly more difficult configuration.

I use the latest version of MMX and the problem described above still occurs sometimes. Today I noticed an additional symptom. I have two methods in class, located next to each other, the same names, but the first one is generic and inactive (marked as a comment). After editing the second one and approving both were moved to the beginning of the class:

Sarina DuPont, comment from 5 months ago: "10.3.3 versions of Delphi and C++ Builder Community Edition remain available for download. 10.3.3 was an excellent release and Community Edition users can perfectly well continue to work with that release. The majority of customers who need the best performance, quality and features should be able to purchase the latest release. Our paying customers deserve a premium experience. That, coupled with increased non-compliant usage of Community Edition (which we're actively addressing with our legal team), has resulted in delaying a new release of CE. Over the coming months, we'll determine when a 10.4 version of CE will be released. Regards, Sarina"

I have a proposal for a new functionality for MMX. It is a simple change, and for me, and I hope other users too, can be very useful. I use prefixes in the names of method parameters, I personally prefer the letters a, o and v for const, out and var parameters, respectively: procedure Somethinghing(const aInput : Integer; out oOutput : string; var vOther : string); Thanks to this, inside the body of the method, I know which parameter has which features and whether I can (var) or should (out) change it. This greatly improves code readability and error avoidance. Of course I write about myself 😉 I suggest adding a function to MMX that could be called "Forcing a parameter name prefix". Of course, the prefix (a, c and o) themselves could be set in the MMX configuration (just like the prefix for object fields). Additionally, in the configuration I would also give a checkbox "Force parameter name prefix", which would be the default value when editing the method (ctrl+E) and which could be incidentally unchecked or checked as in the picture: Using the "force prefix" option would work in such a way that if the parameter has some prefix (lowercase letters in front, before uppercase) they would be replaced, e.g. xParam -> aParam, xyParam -> aParam, and if the parameter has no prefix then it would be added, Param -> aParam Does this idea seem good to you and you would take it up?

@Kas Ob. Maybe you should put on a new thread with your proposal, this one concerns my proposal, ok?

Ok, I actually assumed that everyone uses lower case letters as prefixes But let's think about the cases. Let's assume that we want to use the letter 'a' as a prefix, in which case all the possibilities of the end result are: name -> aname Name -> aName Array -> aArray array -> aarray ?? When the beginning of the name already contains a small 'a' (in case of re-editing), it is enough to check if the beginning is consistent with 'a', only the last example introduces an ambiguity, because 'array' starts with 'a' and it is not known if it is a 'rray' with an added prefix or 'array' without a prefix. In this case, I would leave 'array' unchanged (which works well for editing the aarray parameter as well). The case with the prefix written in capital letters 'A': name -> Aname Name -> AName Array -> AArray ?? array -> Aarray In this case, the third case (Array) is ambiguous. I would leave it unchanged, similarly as above. These conditions do not seem very complicated, have I overlooked something?

As I wrote in the first post this functionality would be optional and configurable.

The Hungarian notation refers to prefixes identifying the type of variable, this is something else. In this case you would have all 3 kinds of prefixes marked as 'a'.

https://www.thedelphigeek.com/2019/04/fastmm4-large-memory.html

Inline was added in D2005: https://edn.embarcadero.com/article/33050

Hi, I found a serious FireDAC bug, I wrote a minimal sample program to reveal it, you need a Firebird server and any database to run. Maybe there is also a problem with other servers, I did not check. The problem occurs when you do not explicitly assign the FDConnection control to the FDQuery, but use the registered Connection Definition Name and assign it by Query.ConnectionName and occurs when Connection Definition Name is used more than once at a time (in thread). The result is a mass of random errors, each time you run it, there are different errors, in a different place of FireDAC code. Source of example, console app: program FDPoolingBug; uses System.Threading, System.Classes, Winapi.Windows, FireDAC.Phys.IBWrapper, FireDAC.Phys, FireDAC.Phys.FBDef, FireDAC.Stan.Intf, FireDAC.Stan.Def, FireDAC.DApt, FireDAC.Phys.FB, FireDAC.Stan.Pool, FireDAC.Stan.Async, FireDAC.Comp.Client, System.SysUtils; {$APPTYPE CONSOLE} {$R *.res} const CONN_DEF_NAME = 'CONNECTION_TO_DB'; var bEnd : Boolean = False; procedure RegisterConnectionDefinition(); var oConDef: IFDStanConnectionDef; oPars: TFDPhysFBConnectionDefParams; begin if FDManager.ConnectionDefs.FindConnectionDef(CONN_DEF_NAME) = nil then begin oConDef := FDManager.ConnectionDefs.AddConnectionDef; oConDef.Name := CONN_DEF_NAME; oPars := TFDPhysFBConnectionDefParams(oConDef.Params); oPars.DriverID := 'FB'; oPars.Server := '192.168.1.10'; oPars.Database := 'Some_FB_Database.FDB'; oPars.Port := 3060; oPars.Pooled := True; oPars.PoolMaximumItems := 100; oPars.PoolCleanupTimeout := 30000; oPars.PoolExpireTimeout := 90000; oPars.UserName := 'sysdba'; oPars.Password := 'masterkey'; oPars.SQLDialect := 3; oPars.Protocol := ipTCPIP; oPars.CharacterSet := TIBCharacterSet.csUTF8; oConDef.Apply; end end; procedure QueryWithAutoConnection(); //This method works incorrectly var lCounter: Integer; lId: Integer; lQuery: TFDQuery; begin lId := GetCurrentThreadId() mod 99; Writeln('start: ', lId); try lQuery := TFDQuery.Create(nil); lQuery.ConnectionName := CONN_DEF_NAME; lQuery.SQL.Text := 'select * from rdb$database'; lCounter := 0; repeat lQuery.Open; lQuery.Close; Inc(lCounter); if lCounter = 1000 then begin lCounter := 0; Writeln(lId); end; until bEnd; except On E : Exception do begin writeln(Format('id: %d, Exception: %s, Desc: %s', [lId, E.ClassName, E.Message])); Writeln; end; end; end; procedure QueryWithDedicatedConnection(); // This method works correctly var lConn: TFDConnection; lCounter: Integer; lId: Integer; lQuery: TFDQuery; begin lId := GetCurrentThreadId() mod 99; Writeln('start: ', lId); try lConn := TFDConnection.Create(nil); lConn.ConnectionDefName := CONN_DEF_NAME; lQuery := TFDQuery.Create(nil); lQuery.Connection := lConn; lQuery.SQL.Text := 'select * from rdb$database'; lCounter := 0; repeat lQuery.Open; lQuery.Close; Inc(lCounter); if lCounter = 1000 then begin lCounter := 0; Writeln(lId); end; until bEnd; except On E : Exception do begin writeln(Format('id: %d, Exception: %s, Desc: %s', [lId, E.ClassName, E.Message])); Writeln; end; end; end; procedure RunOne(); var aTask: ITask; begin aTask := TTask.Create(QueryWithAutoConnection); aTask.Start; TTask.WaitForAll([aTask]); end; procedure RunParallel(lThreadCount : Integer); var aTasks: TArray<ITask>; i: Integer; begin SetLength(aTasks, lThreadCount); for i := 0 to Pred(lThreadCount) do begin aTasks[i] := TTask.Create(QueryWithAutoConnection); Sleep(10); aTasks[i].Start; end; TTask.WaitForAll(aTasks); end; begin try RegisterConnectionDefinition(); //RunOne; RunParallel(3); Readln; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end. Can someone check it in Delphi 10.4.1? I use Delphi 10.3.

And unfortunately this is a certain inconsistency, because when I create FDConnection and assign it ConnectionDefName, a physical, new connection is taken from the pool. Why doesn't he do it with Query if he gets a new, automatically created FDConnection in the same way? Couldn't this new FDConnection also get a new, unique connection from the pool?

I downloaded GExperts sources and tried to build... without success, I get error on prebuild step: PreBuildEvent: call ..\..\images\_CreateGXIconsRc.cmd&&call ..\..\buildtools\prebuild.cmd "d :\Work\GExperts\Projects\DelphiXx103\GExpertsRS103.dproj"&&call ..\..\buildto ols\movedll.cmd "d:\Work\GExperts\Binaries\GExpertsRS103.dll" generating GXIcons.rc in d:\Work\GExperts\Images Borland Resource Compiler Version 5.40 Copyright (c) 1990, 1999 Inprise Corporation. All rights reserved. Nazwa pliku jest powtórzona, albo nie można odnaleźć pliku. C:\Program Files (x86)\Embarcadero\Studio\20.0\bin\CodeGear.Common.Targets(402, 5): error MSB3073: The command "call ..\..\images\_CreateGXIconsRc.cmd&&call .. \..\buildtools\prebuild.cmd "d:\Work\GExperts\Projects\DelphiXx103\GExpertsRS10 3.dproj"&&call ..\..\buildtools\movedll.cmd "d:\Work\GExperts\Binaries\GExperts RS103.dll"" exited with code 1. [d:\Work\GExperts\Projects\DelphiXx103\GExperts RS103.dproj] Done Building Project "d:\Work\GExperts\Projects\DelphiXx103\GExpertsRS103.dpro j" (rebuild target(s)) -- FAILED. Error message "Nazwa pliku jest powtórzona, albo nie można odnaleźć pliku." after translate to english means: "The file name is duplicated or the file cannot be found.'" But which file?

Ok, I forgot FDManager.Active := True; at the end of the RegisterConnectionDefinition() method, but it doesn't change anything, after adding the errors are the same. And as for the connection... I don't use the same connection, I use a pool that is managed by FireDAC, so I assume that for every query it gives a new connection, isn't that how it should work? from documentatio9n: "The ConnectionName property value must be specified before Prepare call. If it matches the name of one of connection definitions, then FireDAC will transparently create connection object and link the dataset with it. "