Jump to content

Javier Tarí

Members
 View Profile  See their activity

  • Content Count

    61

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Javier Tarí

  1. Posted · Edited by Javier Tarí

    On 10/3/2020 at 8:41 AM, ConstantGardener said:

    ...have a Look at NexusDb

    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

    • Thanks 1

  2. Posted

    2 hours ago, Fr0sT.Brutal said:

    Usually if you reach the limits of TTable or experience very high memory consumption, it means you have wrong structure ("select * from DAMNBIGTABLE" + TTable + DBGrid with possibility to fetch billions of records). 

    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

  3. Posted

    25 minutes ago, Lars Fosdal said:

    If you want to keep the Paradox tables but change the access method - I'd question if it is worth the hassle.

    If you are going to migrate, why not do it properly?

    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.

     

  4. Posted

    1 hour ago, Fr0sT.Brutal said:

    So you suppose everyone is aware of the Paradox performance?

    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

     

    1 hour ago, Fr0sT.Brutal said:

    Multiuser with hundreds of tables? On Paradox? You're such a joker!

    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

  5. Posted

    5 hours ago, Fr0sT.Brutal said:

     

    You weren't asking for any additional requirements. (Snip)

    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

     

    1 hour ago, Dmitry Arefiev said:

    But anyway, you will never get 100% similar performance to BDE/Paradox TTable with big tables. Any TxxxTable will request DB server and will fetch the data. When data is fetched, then operations will be fast and similar to TTable.

    That kind of emulation is, as I mentioned before, a joke

    At least if you are in multiuser, hundreds of tables, and millions of registers

     

    Reminder: I'm not asking for something impossible; as I mentioned in original post, ElevateDB delivers what I'm looking for

     

    Will try NexusDB asap

     

  10. Posted · Edited by Javier Tarí
    Correction

    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

  13. Posted

    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

  14. Posted

    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

  15. Posted

    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

  16. Posted

    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

    • Like 1

  17. Posted

    On 8/26/2020 at 6:04 PM, Anders Melander said:

    That only resolves inter-package dependencies. Not application dependencies.

    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

  18. Posted

    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

    • Like 5

  19. Posted

    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

     

     

  21. Posted

    17 minutes ago, Bill Meyer said:

    Stefan Glienke, to whom I defer.

     

    In my experience, one of the most common patterns in Delphi legacy apps is the anti-pattern of large routines on forms in event handlers. That is something the double-click on a button and write code makes all too common. Thoughtless coding. Patterns are no guarantee of good design.

    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

    • Like 1

  23. Posted

    1 hour ago, Bill Meyer said:

    Particularly since MVVM appears to have been created largely to fit the specifics of C# and XAML.

    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?

  24. Posted

    1 hour ago, Anders Melander said:

    Nothing is stopping you from doing DI. Why do you need that "in the box"?

    As for MVVM I'm not convinced Delphi should do it at all. Not every pattern fits every language.

    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

     

     

     

  25. Posted

    Everywhere but in Delphi, we see MVVM, MC, MVP  architectural patterns

    Everywhere but in Delphi, many techniques as Dependency Injection are common

    About DI, there is some work out there, but MVVM and such, just doesn't exist

    All that should come in the box

    IMO, Delphi programming hasn't changed so much on the latest 25 years.

    Yes, I program since D1, and before that, since Turbo Pascal 3

     

    • Like 1
×