I’m using Delphi to develop my custom DA application server. Over the years, my DA service grew big and has hundreds of Data Tables and Commands. I understand, from performance perspective, there might not be to much penalty to pay, since when a service just finds the Data Table to serve among a few hundreds of names. My issue is that this starts to be a bit hard to maintain and manage. Splitting the tables in more than one DA services I guess is one option, but this requires switching between ServiceName in the TRORemoteService component on the client side when a form will require Data Tables from 2 or 3 DA services.
Is there a best practice for this I’m trying to do? Am I missing something that I should know by now, after using DA for years, to achieve this?
P.S. In my Database I use schemas for logical separation of tables and procedures.
With Hydra you divide your services into plugins (therefore separate projects) allowing you to better manage and evolve your application server.
Personally I have been using it for over 15 years and I couldn’t do without it. All my most important projects are developed with RO/DA and HY
I use Hydra in Server and Client side.
I am looking forward to the possibility of using HY also for DA services for Linux (only service pluging and Non Visual Plugin) … let’s see if there will be an evolution in this sense
Chris,
That is is a very good question. I would also like to know how to handle this type of problem. Multiple schemas with multiple connections on server. We just finished a SwiftUI IOS app for an HVAC client where we have used DA as the backend server but we have only been able to use a single database connection. Works for what we are doing for the one client but will definitely not work for our long term needs.
We have different databases with different schemas that I have would like be able to setup on the same custom server. Cannot use Relativity. Does not connect to some of our older databases.
System database to hold base company user login. System Schema.
Company databases for each individual company and its associated data. User individual login is maintained there. Company Schema. All companies of same type have the same schema. A different type of industry ( HVAC, Catering, Security, etc ) have different schemas based on specific industry.
We have a System database that is our first connection for a user where the user company assignment is verified. From the System, we determine possible company assignment and which Company database to then direct them to.
I know the power of Hydra and what it can do, I already use it too to divide my services,
depending on a logical separation. What I’m saying, what happens when one of those
plugin services gets too big? You divide again? And then your client has to retrieve data tables from 2 or 3 services, this means you have to keep more than one TRORemoteService components on a form. Something I can think of, that could solve what I consider a problem in my case, is maybe DA Service could support a list of Schemas, and not just one, that will be joined under one Service name. Probably this can be done with a bit more coding than just assigning a DASchema component to a DA Service.
Absolutely Anton. We have many old Sybase ASA 7 installations. If you look at older posts from us, we mentioned this several years ago. Next question may be - why don’t you upgrade those to the current version. Well that is based on the customer having some older systems that were custom built by others and we cannot upgrade those. On the database anyway. But we still build against them.
In the Schema Modeler, we cannot connect to Sybase ASA 7. We can connect to Sybase ASA 12 and above. So we model in 12 and then create the custom server with an AnyDac ODBC connection and go from there. Sybase 12 has ADO.Net. To my knowledge, ASA 7 does not. Could be wrong though. I often am.
Theoretically it could be possible to work via ODBC.NET or OLEDB.NET drivers, however I am not sure that there won’t be any stability or performance issues.
Any chance for a reply on the main topic ?
Anyway, I have thought and almost implement a solution, I will drop as many TDASchema components on my DataAbstract service module, each loaded with a schema, and upon creation of the service, it will iterate and find all those TDASchema components and merge all Datasets and Commands in one and store it in a Schema object pool I created, and each service upon creation will assign the ServiceSchema with an instance from the Object pool, so it won’t have to execute the merging again.
I split my server services in modules. Each module have Dataservice and Service. Each data service have own schema with tables. That fit also my Postgres schema structure.
At client side have client data modules, each one connecting to correspondent Server DataService pointed to one schema.
I load schema files at runtime.
Also use that’s schema files to generated stronged types and access to datatables using interfaces.
I find this structure very scalable and easy to maintain.
I never use hydra because my server need to be deployed to linux intel/arm. For linux intel I use Delphi and for linux arm use fpc/lazarus.
If hydra supports that platforms in the future for sure will use plugins.
Actually, I don´t building a linux daemon. Im just using a console app, controlling that with a script running via crontab at boot and restarting automatically if is down for any reasons.
Theres a few samples for real linux daemon build with delphi on the net. This one for example.
?