Javier Tarí

This surprised me a lot, and I believe (hope!) is a very good sign: "Recently we launched a new experiment of opening up some internal projects for MVPs to work on. As opposed to some of our open-source initiatives like Bold, these are still owned by Embarcadero and a primary part of the product." https://blogs.embarcadero.com/update-xml-mapper/

Does someone know a TTable replacement that really works? It should have about the same performance than paradox, with hundreds of tables, many with millions of registers Changing from ttable-kind to TQuery-kind is not an option at this time: it will be done at a later stage Currently the only DB I know capable of this is ElevateDB; but I'd like to know if there are more possibilities It is an actively developed program, with hundreds of installations that started 20 years ago with D5 and Paradox, and today is with D10.4 and still paradox It must be solved in order: first change from paradox to a server based database, SQL capable Once that is finished, there are plans to slowly migrate from TTable-ish to TQuery-ish Thanks

A truly good advice: followed it and my application is now running smoothly on NexusDB, with almost no changes at all As I don't use the native components, but descendants wrapping Ttable, TDatabase, and so on, the changes needed to substitute BDE for NexusDB have been made only in that unit

Remember is just paradox with TTable, so no select, no queries. You just open the table and it doesn't matter if it's 10 records or 10 millions. If you stick to locate, SetRange, it will always be light speed When you need to crunch records, then it fall to it's knees and cryes

Nonono... I want both to first get rid of paradox, and get rid of TTable access method But I can't just rewrite the whole application in a step So 1st I would get rid of Paradox, keeping the access method, so the app still works And then change the access method through the whole application, step by step.

My bad; you're right. I'm so used to it that forget it's so old that currently it is unknown territory for most people I understand that you don't have real experience with it, as it was already dead when you finished school Yes, I have lots of installations with Paradox, and didn't had trouble till some W10 updates started breaking it all I don't have experience with more than 50 concurrent users, so I can't talk past that point. With 50, it works (worked) fine Not that the configuration for that to work was easy at all, but once you know how to do it, it's a matter of making your program self-check and self-configure it on the computer it's running, and that's it

I asked this: It should have about the same performance than paradox, with hundreds of tables, many with millions of registers And the proposed solution does not deliver that at all Thanks anyway

No luck... Seems TZtable implementation is also a useless one, loading the whole table in memory: https://zeoslib.sourceforge.io/viewtopic.php?t=11296

When I tried it, many years ago, the implementation was awful: it loaded the whole table in memory A joke instead of a tool

Why?

Will try It; thank you I discarded It due to a confusion regarding the engine distribution and AWE server

Currently I'm migrating a project from D2007 to D10.3, and geting false differences on DFM files, due to a change on the order of some properties when the IDE saves a form to a DFM file The properties have the same values, but with D10.3 they are saved on a different order Any idea on how could I change that order? If the fix needs a change on the components, no problem: I use almost always my own components inherited from the standard ones, even TLabel Thanks in advance

Didn't knew it; I'll give it a shot Seems quite interesting, thank you

Yes, but if it was already published, it does nothing

Found this: The serialization order depends on the order the porperties have been published. So you the properties you publish on inherited components will be serialized after the the ancestor component published properties So seems I'm mostly out of luck, unless I modify the VCL sources on D2007, publishing the properties that exists on both, but are unpublished on D2007

When you compile a package, you can findi in Project->Information for ProjectName a listbox with all the packages it needs I'd like to get that list so I can have all included in the application installer Otherwise, I just get a message "Can't find the specified module" Any help would be largely appreciated

I found a valid way to get that list, althought a bit convoluted Just in case someone needs it: On the IDE, Project menu, Deployment There you can find all the bpl needed; mark them all, and save the project Then open the project file (it's XML); you will find a section with all those files: <ProjectExtensions> <BorlandProject> <Deployment> <DeployFile LocalName="$(BDS)\Redist\Win32\soaprtl260.de" Configuration="Debug" Class="DependencyPackageResource"> <RemoteName>soaprtl260.de</RemoteName> Parse this, get the "RemoteName" values that have .bpl extension, and you're done

My fault... I'm so used to work with an app that is just the launcher for the main package, that didn't thought on it at all My exe just loads the main package and launches a given exporte procedure there, that's almost all it does

If you are interested in performance, http://kluug.net (Ondřej Pokorný) has two excellent libraries; the freeware OmniXML and the commercial OXml. I'm user and customer of OXml On this page: http://kluug.net/oxml.php choose the Performance tab and you will see a thorough comparision between most Delphi XML libraries. OXml shows about 10 times faster than MSXML I purchased both OXml and OExport, and quite happy with them Note: No, I'm not related to Kluug in any possible way, other than customer/user of his librtaries

I've always worked with runtime packages, but I always deploy all of them The easiest way to check if a package can be loaded, is just loading it: function LoadPackage(const Name: string): HMODULE; overload; function LoadPackage(const Name: string; AValidatePackage: TValidatePackageProc): HMODULE; overload; LoadPackage loads the package specified by the Name parameter, checks for duplicate units, and calls the initialization blocks of all units contained in the package

Funny enough, LiveBindings seem to fit MVVM or just MVx We didn't had it before, and they seem overkill just to avoid having DBaware components

I found this forum searching for anything related to MVVM and Delphi; there is a Stefan post here where he says something on the line of Delphi MVVM won't work together I have the book; I've read most or perhaps all that is written about MV* and Delphi I'm working with some friends towards MVVM, but time is scarce Delphi programming makes way too easy writing messy code, with iron-clad coupling between interface code and business rules That's a big point against Delphi

No, that's a REST framework; quite good, but not related to MVC UI implementations I don't know where the MVC in the name it comes from And about MVVM, zero Just old posts and such; no working solution at all

You provided a good example of what I'm arguing... Do you mean that in Delphi we don't need MVC, MVP, MVVM and so on? Or perhaps is just that in Delphi we don't have anything like that?

It doesn't matter if you like MVx or not, because with Delphi you can not use ANY of the MVx patterns It does not exist any Delphi framework for MVVM, nor MVC, nor MVP... Zero, zilch, Nil Delphi developer base is... Quite senior And seems between us there is not much interest in these kind of tools