We are getting close to a decision on moving to XSharp but it's imperative that we migrate our databases from dBase to MS SQL. What are the mechanisms available in XSharp to handle MS SQL tables? Any SQL libraries or something similar we could use to simplify managing SQL tables?
We migrated our main VO application to SQL utilizing VO2ADO which I assume will be of no use in XSharp but in VO we were able to declare servers and then add all the server methods needed to manage data, what is available in XSharp to simplify programming and management of large MS SQL data? Need help here... if we start on the conversion we would first port everything to XSharp using dBase databases and then as a first step, use the same dBase database structure to create MS SQL tables and substitute these in the application. This is not an optimized solution but a first step to enable us to install our client applications in a cloud and meet safety requirements.
We have new MS SQL redesigned tables but these require a major rewrite of our application and that is not economically feasible at this point and we must move forward or fail.
Any sample code so that we may see the connection and access design and perhaps commence modifications to accommodate this?
Thanks, it is very urgent. We have hired an external database expert consultant to provide input to my partner to make this decision which is crucial for our business. Appreciate input and directions, I need to explain the feasibility of this migration tomorrow.
John
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
Hello John,
No idea if this could be of any help but I'll give it a try. Years ago, VO "guru" Geoff Schaller wrote a program called SQLMaster. It was designed to use SQL data with the DBF programming. From there you could start optimizing the code; obviously things like DO..WHILE loops with every time a SQL query executed needs rewriting.
This is one of the newsgourp links about it https://groups.google.com/forum/#!searc ... vgZvpWjWgJ but I saw that the download link does no longer exist on Geoff's software company Software Objectives.
You could contract him to see if there's a source code version available that you can convert to X#. Otherwise indeed I doubt if you can implement SQL in a DBF based program without major rewrites.
Dick
No idea if this could be of any help but I'll give it a try. Years ago, VO "guru" Geoff Schaller wrote a program called SQLMaster. It was designed to use SQL data with the DBF programming. From there you could start optimizing the code; obviously things like DO..WHILE loops with every time a SQL query executed needs rewriting.
This is one of the newsgourp links about it https://groups.google.com/forum/#!searc ... vgZvpWjWgJ but I saw that the download link does no longer exist on Geoff's software company Software Objectives.
You could contract him to see if there's a source code version available that you can convert to X#. Otherwise indeed I doubt if you can implement SQL in a DBF based program without major rewrites.
Dick
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
Thanks for your reply. There has to be some solution to being able to reuse our working VO code in a new environment and migrating data to SQL in a simple manner.
There must be others with the same problems we are facing, basically, we have fully developed and working VO applications that are our bread and butter, we use them to process large amounts of client data to run their opearations.
I'm not giving up. There must be some easier solution to this problem. Originally we were moving to Vulcan.net and we purchased their latest version, however, we have been aware of their development problems and wanted to avoid entering again into another VO development fiasco. We need solutions.
Regards,
John
There must be others with the same problems we are facing, basically, we have fully developed and working VO applications that are our bread and butter, we use them to process large amounts of client data to run their opearations.
I'm not giving up. There must be some easier solution to this problem. Originally we were moving to Vulcan.net and we purchased their latest version, however, we have been aware of their development problems and wanted to avoid entering again into another VO development fiasco. We need solutions.
Regards,
John
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
Hi Dick,
I can no longer find Geoff Schaller, his email geoffsch@bigpond.net.au returns an error and the bigpond web site is no longer available. Do you have any idea how to locate him?
Thanks,
John
I can no longer find Geoff Schaller, his email geoffsch@bigpond.net.au returns an error and the bigpond web site is no longer available. Do you have any idea how to locate him?
Thanks,
John
-
NickFriend
- Posts: 248
- Joined: Fri Oct 14, 2016 7:09 am
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
Geoff had a company called Software Objectives in Australia. I just checked and it's still there so you should be able to get the contact details there.
Nick
Nick
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
Nick, thanks for the information. I found Geoff's company and have sent him an email. Rgds, John
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
Hi John,
as I wrote in my mail: you have several possibilities for a move to SQL.
There is not only Geoff Schallers software, but there is also a (VO) RDD for MySQL by Alessandro Vacchiano, that could be ported to X# and other SQL like MS SQL.
And there is a DataServer class that uses PostgreSQL by Phil McGuiness, that will be donated to the X# community.
But I would write my own database layer basing my server classes to ADO.NET - or, if you really in a hurry, ADS (Advantage Database Server) could be an option.
And there are talks about a DBF Server product written by the X# development team, based on their DBFCDX RDD.
You should do some analysis how do you are using DBFs: maybe a move is simple, but it could also be a difficult thing if you are using some specialities that only DBFs give (like an easy copy back and forward of files with configurations).
Please don't forget: there are many specialists in the VO/X# community that can help, including the X# team itself.
Wolfgang
as I wrote in my mail: you have several possibilities for a move to SQL.
There is not only Geoff Schallers software, but there is also a (VO) RDD for MySQL by Alessandro Vacchiano, that could be ported to X# and other SQL like MS SQL.
And there is a DataServer class that uses PostgreSQL by Phil McGuiness, that will be donated to the X# community.
But I would write my own database layer basing my server classes to ADO.NET - or, if you really in a hurry, ADS (Advantage Database Server) could be an option.
And there are talks about a DBF Server product written by the X# development team, based on their DBFCDX RDD.
You should do some analysis how do you are using DBFs: maybe a move is simple, but it could also be a difficult thing if you are using some specialities that only DBFs give (like an easy copy back and forward of files with configurations).
Please don't forget: there are many specialists in the VO/X# community that can help, including the X# team itself.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
-
lumberjack
- Posts: 723
- Joined: Fri Sep 25, 2015 3:11 pm
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
Hi John,
One thing I would consider is to not replicate bad habits when moving to X#. It is an ideal time to do some re-engineering as part of the migration. I for example did not try to even use DBF anymore when I initially moved to Vulcan and wrote some wrappers around my data access that are re-used consistently in interfacing to the Db server. Well I was probably lucky because I already used the same type of layer around DBFs in VO. Is MS SQL the only option you have? If not, then I would also look at open source solutions like PostgreSQL.
Just my 2c...
How easy the move will be I believe depend on how "hard coded" your DB interfaces layers are.jjgregg wrote:There has to be some solution to being able to reuse our working VO code in a new environment and migrating data to SQL in a simple manner.
There must be others with the same problems we are facing, basically, we have fully developed and working VO applications that are our bread and butter, we use them to process large amounts of client data to run their operations.
There must be some easier solution to this problem. Originally we were moving to Vulcan.net and we purchased their latest version, however, we have been aware of their development problems and wanted to avoid entering again into another VO development fiasco. We need solutions.
One thing I would consider is to not replicate bad habits when moving to X#. It is an ideal time to do some re-engineering as part of the migration. I for example did not try to even use DBF anymore when I initially moved to Vulcan and wrote some wrappers around my data access that are re-used consistently in interfacing to the Db server. Well I was probably lucky because I already used the same type of layer around DBFs in VO. Is MS SQL the only option you have? If not, then I would also look at open source solutions like PostgreSQL.
Just my 2c...
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
John,
Vo2Ado is also available for X#. You should be able to migrate from VO to X# and keep using that. There is a special version of Vo2Ado for .Net (vn2ado, soon to be called xs2ado) which works just like the vo2ado for Visual Objects.
Robert
Vo2Ado is also available for X#. You should be able to migrate from VO to X# and keep using that. There is a special version of Vo2Ado for .Net (vn2ado, soon to be called xs2ado) which works just like the vo2ado for Visual Objects.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
-
NickFriend
- Posts: 248
- Joined: Fri Oct 14, 2016 7:09 am
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
As Johan said, it will depend massively on how isolated, or not, your DBF access code is.
If you access DBF files throughout the source code, then I think the only options are a complete rewrite or some sort of emulation library like Geoff's or Alessandro's.
If you have a clearly defined data access layer with all the DBF access code there and returning objects that are then used in the rest of the code, you could replace it with something to access a SQL db.
In this latter case, Entity Framework could be very useful as it abstracts out the database access and lets you work with objects. It's not the fastest way to handle a db, but the level of abstraction makes it worth while.
Nick
If you access DBF files throughout the source code, then I think the only options are a complete rewrite or some sort of emulation library like Geoff's or Alessandro's.
If you have a clearly defined data access layer with all the DBF access code there and returning objects that are then used in the rest of the code, you could replace it with something to access a SQL db.
In this latter case, Entity Framework could be very useful as it abstracts out the database access and lets you work with objects. It's not the fastest way to handle a db, but the level of abstraction makes it worth while.
Nick