Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB Connectivity » View Thread |
Messages 1 to 6 of 6 total |
considering adding .NET |
Fri, Apr 26 2013 1:52 AM | Permanent Link |
David Cornelius Cornelius Concepts | 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 |
Fri, Apr 26 2013 8:22 AM | Permanent Link |
Raul Team Elevate | 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 |
Fri, Apr 26 2013 8:50 AM | Permanent Link |
David Cornelius Cornelius Concepts | 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 |
Mon, Apr 29 2013 12:29 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Mon, Apr 29 2013 12:32 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Mon, Apr 29 2013 7:26 PM | Permanent Link |
David Cornelius Cornelius Concepts | << 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 |
This web page was last updated on Thursday, May 23, 2024 at 07:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |