This question came in from a Delphi user group coordinator:
One of the people interested has a big project written and maintained in Delphi 2007 and uses Firebird as the database. I read the System Requirements in the documentation on your website and see that Rubicon 4 fully supports Delphi 2009+. But what does that mean for older versions?
Hi. I will give you two opposite answers. It depends primarily on which database access components are being used.
It is impossible to support Delphi 2007 because too many namespaces have changed and too many fundamentally helpful details have been added in recent Delphi. e.g. AnyDAC became FireDAC, and their wobble on the required units has stopped, making our uses clauses much more reasonable for that bridge. All our good sample projects for FireDAC came in well after year 2007.
It should be possible to tell you which Rubicon subversion tag had the last support for Delphi 2007, and if you compiled with that source, using a bridge that was supported back then (IBObjects? IBExpress? UniDAC?) , you would most likely be able to make it work. It would be extremely difficult for us to support you on the old code, so even though we could offer sympathy, the pressure would be always be to upgrade Delphi.
And. We have only recently been working on real Update & Append support for SQL. So you’d have to re-build the index periodically.
Doing a quick search on Rubicon release notes, https://www.href.com/rbrelnotes, I find that v3.088 from 30-Sep-2011 had Delphi 2007 support. IProviderSupport came in after Delphi 2007, as did win64, as did CodeSite Express via GetIt.
Of course, one way forward is to manage full text search features in a separate EXE compiled with Delphi 11, and communicate those results through to the older system “somehow.” I would have lots of ideas about “somehow” if that were of interest.
I get pretty sentimental about old versions, especially Delphi 2 and Delphi 7. I definitely understand not wanting to ugprade.
Best wishes for your project.
Thanks for posting this question for me and providing the solution possibilities to consider. I know the guy and his product, an insurance agency management application. The most likely path forward is there will be a new application written that serves both web and mobile customers to incorporate new features and slowly replace the legacy Windows app.
I can see how an insurance agent might want some advanced searching capabilities if they’re looking for a document or a policy and can’t remember the customer; or if they want to pull out statistics that match certain criteria.
Many possibilities if the data is organized properly and indexed.
I am all in favor of rewrites that leverage HTML and CSS and work on all platforms.
Dany ( @SleekProductions ) recently talked us into adding a feature that enables a hybrid search where Rubicon’s index is used to get the global list of matching PKs yet any custom rules, e.g. from Firebird SQL in any way limited only by the developer’s imagination, can be used to validate whether or not a given PK ends up in the result the end-user sees. This is the “OnPreviewLocation” event handler on the TrbSearch component. So for example, maybe the insurance agent searches for “flooding catastrophe” and the app knows to restrict the search further based on whatever it already knows about the agent’s job.
Many possibilities. Probably more than we can ever code in one lifetime. Fun to try though.