ROSDK and DataAbstract Advice needed

Data Abstract
1

I am going to start a new project that will need ROSDK/DA, and fast delivery.

I am hesitating between the two platforms Delphi or .NET

I have used ROSDK/Delphi before, but never used .NET with ROSDK

I am not sure of the learning curve of ROSDK/DA on the .NET side, maybe harder/trickier than I thought.
In the long run, we will adopt NET for sure because it is easier to find good NET programmers than Delphi.

Any advice, pitfalls or heads up that I should be aware?

Thank you

2

Hello

Some things like async client → server calls and client-side dataset management are different.
Some API and approaches are different because sometimes Delphi APIs just don’t fit into the recommended .NET approach.
Also DA LINQ (and the whole LINQ conception) might look a bit confusing at the start.

These 2 tutorials should help you to get the feeling of SDK and Data Abstract for .NET:

Just ask questions (here or at support@ ) if you get stuck

1 Like
3

@antonk Thank you for the advice.

One last question: If the requirement is to have a CPU native server, I guess Delphi would be the only choice?

4

In terms of Data Abstract - yes.
However it won’t be faster than a .NET Core server because
a) It will use JIT which means that .NET program is compiled into a CPU-native instructions at runtime
b) Anyway network latency and database access time won’t go anywhere so the performance will be more or less the same

2 Likes
5

I took the dive and switched over from Delphi to .NET a few years ago due to my disappointment with where the Delphi product was going.

There was a learning curve, but with Oxygene it was minimized. There was also a slight learning curve for WPF but in the end that is worth it over WinForms, IMHO.

Re: DA/ROSDK - DA hides all the ROSDK coding unless you are doing ROSDK in addition to DA. In terms of DA it is just awesome on .NET. DALINQ (and LINQ in general) make the switch to .NET worth it. Being able to write LINQ statements as code makes your code so much more readable and in the end smaller.

I would suggest you go the .NET route and just give yourself time enough for a good learning curve.

2 Likes
6

@aolson
Thank you very much for the valuable advice. Well taken!

7

In addition to what Alan said, I wanted to add: while DA iOS of course slightly different on each platform to fit in well, the underlying concepts are the same on all platforms, so I would day the bulk of the learning curve for DA is platform independent, and if you are familiar with DA on one platform(i.e. Delphi) and familiar(ish) with the basics of the new platform (i.e. .NET), then getting used to DA on the new platform should be a breeze.

8

If I use Delphi for DA Server, and .NET for DA Client, would I still be able to use DaLinQ?

The reason that Delphi DA Server is considered is that - I found Delphi seems to have better(i.e., faster) database access drivers than ADO.NET

9

Anton will know for sure, but I believe at least full-featured DA LINQ builds on DA SQL, which is only supported by .NET servers.

10

Relativity server is your other option and what I use…

11

Isn’t relativity server a .NET server that internally uses ADO.NET? @aolson

The reason Delphi DA Server is being considered is that Delphi data access driver (UniDAC) seems faster than ADO.NET, especially for the NexusDB database I will be using.

12

Hello

It is.
That said, ADO.NET database drivers should be faster or have the same data access speed as the ones used in Delphi, at least for major data providers like MS SQL, PostgreSQL, Oracle etc.

Yes, you would be able to use DA LINQ, however it will be limited.
It is possible to switch DA LINQ data provider into an alternate data access mode.
In this mode DA LINQ uses DynamicWhere statements to represent queries. This means that such data queries can be processed by Delphi server too. However this comes at a price - not every valid DA LINQ query can be processed in that mode. F.e. function calls in the WHERE clause, table joins etc cannot be represented as a DynamicWhere statement, so they cannot be processed in that alternate mode.

This means that this query would be successfully processed:

var query := from j in self.LinqAdapter.GetTable<Jobs>()
                         where (j.OrderDateField.Day = 1) and (j.OrderDateField.Month = 8)
                         select j;

And this one contains method calls ( .ToUpper and .Contains )

var res := from x
         in self.LinqAdapter.GetTable<Clients>()
         where x.CustomerIDField.ToUpper().Contains('F') select x;

so it cannot be represented using DynamicWhere only. In case of DA SQL this query would be translated into a SQL statement containing corresponding database server function calls.

Regards

15

Thank you for the explanation. In the case below, is the “translation” transparent to the .NET Client and silently handled by the Delphi DA server, or the Delphi DA server will raise an exception when method calls are involved in the .NET client side?

16

If DataAdapter’s property UseDynamicWhere is set to true then client will raise an exception like

RemObjects.DataAbstract.LinqException: Method System.String.ToUpper is not supported

This exception is raised while request to the server is being prepared so nothing is being sent to the server. This is client-only exception.

If DataAdapter’s property UseDynamicWhere is set to false then client will convert this DA LINQ query into a corresponding DA SQL statement and will send it to the server. After that Delphi DA server will raise an exception that will be sent back to the client.

1 Like