Leaderboard

Today, almost all computer security relies on asymmetric cryptography and X.509 certificates as file or hardware modules. And the RSA algorithm is still used to sign the vast majority of those certificates. Even if there are better options (like ECC-256), RSA-2048 seems the actual standard, at least still allowed for a few years. So we added pure pascal RSA cryptography and X.509 certificates support in mORMot 2. Last but not least, we also added Hardware Security Modules support via the PKCS#11 standard. Until now, we were mostly relying on OpenSSL, but a native embedded solution would be smaller in code size, better for reducing dependencies, and easier to work with (especially for HSM). The main idea is to offer only safe algorithms and methods, so that you can write reliable software, even if you are no cryptographic expert. 😉 More information in our blog article about this almost unique features set in Delphi (and FPC): https://blog.synopse.info/?post/2023/12/09/Native-X.509-and-RSA-Support

Why BDE with D12?

Try Zeos - they are Open Source, with very good support. And if you need direct DB access, you can use their ZDBC API which bypasses the TDataSet component so is faster, e.g. for a SELECT with a few rows.

From my codebase: // disable range checks and overflow checks so that Abs() functions in case Value = Low(Value) {$R-} {$Q-} function CopyIntegerToAnsiBuffer(const Value: Integer; var Buffer: array of AnsiChar): Integer; var i, j: Integer; val, remainder: Cardinal; negative: Boolean; tmp: array [0..15] of AnsiChar; begin negative := Value<0; val := Abs(Value); Result := 0; repeat DivMod(val, 10, val, remainder); tmp[Result] := AnsiChar(remainder + Ord('0')); Inc(Result); until val=0; if negative then begin tmp[Result] := '-'; Inc(Result); end; Assert(Result<=Length(Buffer)); i := 0; j := Result-1; while i<Result do begin Buffer[i] := tmp[j]; Inc(i); Dec(j); end; end; function CopyIntegerToWideBuffer(const Value: Integer; var Buffer: array of WideChar): Integer; var i, j: Integer; val, remainder: Cardinal; negative: Boolean; tmp: array [0..15] of WideChar; begin negative := Value<0; val := Abs(Value); Result := 0; repeat DivMod(val, 10, val, remainder); tmp[Result] := WideChar(remainder + Ord('0')); Inc(Result); until val=0; if negative then begin tmp[Result] := '-'; Inc(Result); end; Assert(Result<=Length(Buffer)); i := 0; j := Result-1; while i<Result do begin Buffer[i] := tmp[j]; Inc(i); Dec(j); end; end; function CopyInt64ToAnsiBuffer(const Value: Int64; var Buffer: array of AnsiChar): Integer; var i, j: Integer; val, remainder: UInt64; negative: Boolean; tmp: array [0..23] of AnsiChar; begin negative := Value<0; val := Abs(Value); Result := 0; repeat DivMod(val, 10, val, remainder); tmp[Result] := AnsiChar(remainder + Ord('0')); Inc(Result); until val=0; if negative then begin tmp[Result] := '-'; Inc(Result); end; Assert(Result<=Length(Buffer)); i := 0; j := Result-1; while i<Result do begin Buffer[i] := tmp[j]; Inc(i); Dec(j); end; end; function CopyInt64ToWideBuffer(const Value: Int64; var Buffer: array of WideChar): Integer; var i, j: Integer; val, remainder: UInt64; negative: Boolean; tmp: array [0..23] of WideChar; begin negative := Value<0; val := Abs(Value); Result := 0; repeat DivMod(val, 10, val, remainder); tmp[Result] := WideChar(remainder + Ord('0')); Inc(Result); until val=0; if negative then begin tmp[Result] := '-'; Inc(Result); end; Assert(Result<=Length(Buffer)); i := 0; j := Result-1; while i<Result do begin Buffer[i] := tmp[j]; Inc(i); Dec(j); end; end; {$IFDEF RANGECHECKSON}{$R+}{$ENDIF} {$IFDEF OVERFLOWCHECKSON}{$Q+}{$ENDIF} No heap allocation. I guess I could avoid that DivMod now and do something better. The main point is that a good runtime library should have building block functions like this that allow us to perform such conversions without forcing heap allocation. The RTL should have functionality like this on top of which all conversion functions can be built. Then the RTL function can be optimised and everyone benefits.

This is all documented. Obviously we can tell you the answers but once you know about New, you can read the documentation to find out the rest of the details. It's really useful to know how to do that.

Another solution that also reduces the binary size is disabling unnecessary Java libraries. By default projects include all kinds of things, like Billing, FireBase, various Google Play services... and if they are not used in the application, they will just be a dead weight.

Why do you want to switch? As far as relational databases are concerned I do fairly see an advantage in switching at all. Just in case you build your own data access framework as Arnaud mentioned Zeos is one alternative and indeed FireDAC was designed for this and the component layer is really 'just' put on top in order to make the layered library more easy to use, to lower the learning curve. FireDAC as far as the command is concerned is/was more ADO.net stylish compared to other component sets. If I remember correctly UniDAC was introduced pretty much around the time AnyDAC (predecessor of FireDAC) showed up in public. The difference is in the nifty detail. From the bird's eye perspective both are more or less pretty much the same. Under the hood both work completely different. Another question is about having being in the position to utilize access to different database systems by one application since the database is already provided by the customer or 'just' being in the position to use a different database for 'the next application'. In the first case have a focus on the unification layers, for example the unified SQL offered by the 'components' and the statements issued to the database. FireDAC in some cases emulates functionality missing in/not offered by the database system. No idea in how far UniDAC goes beyond what's offered. The authors of FireDAC e.g. in case of Oracle had a focus on doing things the way they are done on the Oracle database. Which for example allowed to have 3000 users accessing a database about 8 to 10 years ago. Working with UniDAC is easier and those components perform very well too. Their advantage is being in the position to access many databases without the need to have a client library installed. As long that is accepted by the customer this direct mode works (very well already) today. There is no thing such as a dedicated support forum. In general what is written in places like this is brought to the attention of the authors or file a request in the official Embarcadero Quality portal. In general: If you are a hobbyist for example feel free to use ZEOS. These component set is easy to use and pretty straight also in case of for example someone who doesn't care a lot about specifics of the underlying database and ZEOS components are pretty straight and well layered too. If you have the choice rely on one database ('forever) and use specific components. I like DOA for Oracle access simply because that's really Oracle just in Delphi and not TDataSet style put on top of the Oracle database. It's ORACLE like when it comes to treating things the ORACLE way in case of CODE Blocks vs. procedures vs. queries in a way things are presented at the database level - kinda 'SQLPlus script' just coded in Delphi. Today few people care about such things.

Check the minSdkVersion value in your projects AndroidManifest.template.xml file. If it's below 21, the packaging tools are unable to use multidex, thus the error. The > 65536 methods refers to how many methods are included in the jar files (in Project Manager, in the Libraries node under the relevant Android target), which grew substantially from Delphi 11.3 to Delphi 12. If the minSdkVersion value is %minSdkVersion%, the IDE replaces it with the default supported value which is 23, in the resulting AndroidManifest.xml in the project output. If this is the case for you, there may be some other configuration issue.

Not sure how relevant this is or if it answers any of your questions but I switched form UniDAC to FireDAC last year. If I still used the Professional edition of Delphi, I'd still have UniDAC; if I needed Direct Oracle Access, I'd still use UniDAC. There are many other reasons to stay--this is just a short story of why I changed and what it took for my small apps.

FireDAC offers very many possibilities. I only know UniDAC for FB. The latter is very far beyond its capabilities. It needs to be well considered. It is a shame to lose them.

I think you should first tell your story. How did you come to the conclusion to change the Universal Data Access Components (UniDAC) to a 'universal database solution'?

Hello to all, As Tommi says, everything is working fine with Delphi 11.3 and the latest VCL release of all the components that I'm using. FastMM 5 was not a problem, and I am sorry for my misunderstanding of this great tool. Again, Tommi's idea is great. Wait for the new release to show its full power. Thanks to all of you again...

I don't know what to think after reading that article. Here are my comments on it: - the classic way of truncating the last 2 digits with div and mod 10 (or 100) does not involve a costly div or mod instruction on modern compilers (*cough* even Delphi 12 now does it - apart from the bugs that came with it) - I think C++ compilers would detect doing a div and a mod instruction and the code they emit would be further optimized so it does not require the "workaround" that the Delphi RTL uses by calculating the modulo by subtracting the div result times 100 from the original value. - the pseudo-code he shows for detecting the number of digits is correct but this is never what gets executed - and you either rewrite this into a few branches (as you can see in the RTL), a C++ compiler might unroll the loop or some other trickery is applied The DivBy100 function was introduced by me in RSP-36119 and I already notified them that DivBy100 can be removed in 12 because now it properly optimizes a div by 100 - however, that affects performance only by like 0.5% or so. As David correctly pointed out the real bottleneck is the heap allocation - and not only a single one when you just turn an integer into a string and display that one but when you concat strings and numbers the "classic" way because then it produces a ton of small temporary strings. That issue even exists when using TStringBuilder where one might think that this was built for optimization. If you look into some overloads of Append you will see that it naively calls into IntToStr and passes that down to the overload that takes string. This is completely insane as the conversion should be done directly in place into the internal buffer that TStringBuilder already uses instead of creating a temporary string, convert the integer into that one, pass that to Append to copy its content into the buffer. This will likely be my next contribution as part of my "Better RTL" series of JIRA entries.