Part 1 - Licensing

I have a Delphi 2010 app using ElevateDB and a license to VCL version of EDB
C/S.  I'm considering doing some stuff in .NET and possibly migrating away
from Delphi (don't get side-tracked, that's a different discussion!) and am
wondering about licensing. If I keep the VCL EDB C/S subscription with its
unlimited-connections server, and want to add a .NET application. (I assume
there's no problem talking to the Win32 server from both a Win32 app and a
..NET app), do I need to get the C/S version of the .NET library, or can I
just get the standard version of that and still connect with unlimited
connections to the server?  I'm thinking that as long as one of my licenses
includes an unlimited-connections C/S server, I'll be fine.  (Eventually, I
could theoretically switch to a .NET C/S license and drop the VCL C/S
license, I presume.)

Part 2 - Oxygene

(This question may shed light on why I'm considering moving away from
Delphi...)  The language I'd choose if I were to do anything in .NET is
Oxygene, partially because it supports Android and will soon support iOS.
My Windows application could be converted to .NET apps (unlikely--this is
just theoretical) and I could use EDB in Visual Studio with Oxygene.  Now,
since I don't understand how they do Android (I guess the compiler output is
compiled Java?), I'm naive enough to ask if EDB works with that, but as I'm
typing this, it's becoming clear to me that it won't because EDB would have
to have a native Android/Java library or "jar" I imagine.

I think I've answered my second question, but would appreciate any
enlightenment from those that know.

Thanks!

--
David Cornelius
Cornelius Concepts

On 4/26/2013 1:52 AM, David Cornelius wrote:
> Part 1 - Licensing
>
> <...> do I need to get the C/S
> version of the .NET library, or can I just get the standard version of
> that and still connect with unlimited connections to the server?  <...>

I would think you can keep your delphi c/s w source since the edb server
is royalty free distribution anyways. Not sure how the .net version
differs in terms of if you need to recompile a custom server.

This is a question sales@elecatesoft.com is best to address

> Part 2 - Oxygene
>
> (This question may shed light on why I'm considering moving away from
> Delphi...)  The language I'd choose if I were to do anything in .NET is
> Oxygene, partially because it supports Android and will soon support

I'm looking at that as well and looks quite promising for those times
that native app is needed.

> Studio with Oxygene.  Now, since I don't understand how they do Android
> (I guess the compiler output is compiled Java?), I'm naive enough to ask

My understanding is same that they always compile to native so Oxygene
for Java compiles direct into JRE executables and uses Java class
libraries etc. Similar for Nougat (iOS and OS X) however here it
compiles direct to native code using objective-c libraries (.net and JRE
are bytecode technically running in virtual machine).

> if EDB works with that, but as I'm typing this, it's becoming clear to
> me that it won't because EDB would have to have a native Android/Java
> library or "jar" I imagine.

I don't know either fully but here is my current understanding.

That's one way to look at it (meaning you need java library or
objective-c library) so EDB would be a problem.

However since EDB is fully written in Delphi in theory at least it
should be possible to convert EDB source to compile natively with
Oxygene - language is supposedly 99% compatible so problem areas would
be around assembly (which i think Tim has gotten rid of in move to
64bit), file system access, tcp/ip communication stack since we cannot
just use winsock and possibly things like critical sections and such
which would need to be OS aware.

I don't think Tim will undertake this so it would be be up to us i'm
thinking to try.

The other option of course is to start switching to more generic access
similar to EWB - EDB server acts as a web server and returns either JSON
or XML datasets and this way Oxygene client has to parse just that. Or
of course Remobjects already sells their Data Abstract that i would
assume works with all Oxygene flavours.

Raul

Thanks for your thoughts, Raul. As I wrote it up, I figured I might need to
send an email directly to ES.  We'll see if there's a response here, first
as others may be interested to know how that works.

<<  However since EDB is fully written in Delphi in theory at least it
should be possible to convert EDB source to compile natively with
Oxygene - language is supposedly 99% compatible so problem areas would
be around assembly (which i think Tim has gotten rid of in move to
64bit), file system access, tcp/ip communication stack since we cannot
just use winsock and possibly things like critical sections and such
which would need to be OS aware. >>

An interesting point you bring up... At first, I only thought of using the
..NET library provided, but converting the source to Oxygene and compiling
that in order to make the library itself cross-platform is another option to
investigate, of course.

<< The other option of course is to start switching to more generic access
similar to EWB - EDB server acts as a web server and returns either JSON
or XML datasets and this way Oxygene client has to parse just that. Or
of course Remobjects already sells their Data Abstract that i would
assume works with all Oxygene flavours. >>

Yes, I've actually been strongly considering this as well.  My client's EDB
server is already on windows in the cloud, so I could quite easily write a
WebBroker app in Delphi 2010 accessing EDB data locally and generating JSON,
then write a client in ANY language on ANY platform to read it in.  That's
probably the direction I'll take, but was curious about what the .NET
component could do in Oxygene.

--
David Cornelius
Cornelius Concepts

David,

<< If I keep the VCL EDB C/S subscription with its unlimited-connections
server, and want to add a .NET application. (I assume there's no problem
talking to the Win32 server from both a Win32 app and a .NET app), do I need
to get the C/S version of the .NET library, or can I just get the standard
version of that and still connect with unlimited connections to the server?
>>

You can do either - it's really up to you and your needs.  I would suggest
that you add the DAC STD purchase/subscription and keep the VCL subscription
until you don't need it anymore, and then have Sam switch it to a DAC
subscription at that point (dropping the extra DAC STD subscription).

<< Now, since I don't understand how they do Android (I guess the compiler
output is compiled Java?), I'm naive enough to ask if EDB works with that,
but as I'm typing this, it's becoming clear to me that it won't because EDB
would have to have a native Android/Java library or "jar" I imagine. >>

Yeah, you won't be able to use EDB with their Android port until we make it
so that EDB is compilable under Oxygene.  Right now, EDB is still using the
older .NET compiler from CodeGear due to compatibility requirements in the
code.

Tim Young
Elevate Software
www.elevatesoft.com

Raul,

<< However since EDB is fully written in Delphi in theory at least it should
be possible to convert EDB source to compile natively with Oxygene -
language is supposedly 99% compatible so problem areas would be around
assembly (which i think Tim has gotten rid of in move to 64bit), >>

EDB never had any assembler - it was always needing to be compiled for
managed code from the beginning, due to the .NET requirement.

<< I don't think Tim will undertake this so it would be be up to us i'm
thinking to try. >>

Actually, I need to switch the EDB .NET Data Provider over to Oxygene
sometime this year.  The .NET Data Provider is still using the old CodeGear
compiler, and it's starting to show its age.  This year is going to be all
about porting, apparently.

Tim Young
Elevate Software
www.elevatesoft.com

<< You can do either - it's really up to you and your needs.>>

Excellent!  That's a very flexible license and helps keep my options open.

<< Yeah, you won't be able to use EDB with their Android port until we make
it
so that EDB is compilable under Oxygene. >>

I'm glad to hear about your plans for supporting Oxygene--another point in
favor of moving to that platform for me.



--
David Cornelius
Cornelius Concepts