Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Upgrade from VFP 8 to 9
- Thread starter iolair
- Start date
- Thread starter
- #21
Sounds good. Does the upsizing wizard help with the SQL, or do you just connect to SQL and go from there?
@Mike Lewis - it was not bad in the Orkneys. A little windy, but the trip back across the Pentland Firth was horrible. Glad Edinburgh is nice. Haven't been in a few years, mostly flew into Glasgow and headed up from there.
Iolair MacWalter
Network Engineer
@Mike Lewis - it was not bad in the Orkneys. A little windy, but the trip back across the Pentland Firth was horrible. Glad Edinburgh is nice. Haven't been in a few years, mostly flew into Glasgow and headed up from there.
Iolair MacWalter
Network Engineer
the upsizing wiz is worse than useless, imho. U need to re-think the data tables a little bit to include primary keys,do a fair bit of data clean-up to clean out duplicate keys,empty keys,orphan keys etc , then use sql bulk xml upload.
you then up with an 'almost identical' sql server db and go from there. I'll be happy to share my prior pain on this , as no doubt will others
you then up with an 'almost identical' sql server db and go from there. I'll be happy to share my prior pain on this , as no doubt will others
Olaf Doschke
Programmer
The upsizing wizard was improved with the Sedna add on to vfp9:
If you want to avoid vfp9 of course that's not an option, you still might give it a try, then you wouldn't need to ask. It does create tables and upload data, if it fails the worst thing that can happen is the sql database is incomplete, it does not break your dbfs, it only reads them,
While clipper has a point for sure, it would save writing your own individual upsizing code.
Of course you will be "punished" by non working upsizing, if you don't have primary keys in your tables. SQL Server does actually also allow tables without primary keys, but it's surely a thing you'll want anyway.
Bye, Olaf.
If you want to avoid vfp9 of course that's not an option, you still might give it a try, then you wouldn't need to ask. It does create tables and upload data, if it fails the worst thing that can happen is the sql database is incomplete, it does not break your dbfs, it only reads them,
While clipper has a point for sure, it would save writing your own individual upsizing code.
Of course you will be "punished" by non working upsizing, if you don't have primary keys in your tables. SQL Server does actually also allow tables without primary keys, but it's surely a thing you'll want anyway.
Bye, Olaf.
Mike Lewis
Programmer
Hang on a moment. Why are we talking about moving the data to SQL Server?
The only reason that SQL Server has come up in this thread was that Iolair said that the developer already owns a copy. That doesn't seem like a good reason for migrating.
I'll argue in favour of SQL Server over DBFs any day of the week, but if the application is working OK, and there are no serious database-related issues, why change?
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
The only reason that SQL Server has come up in this thread was that Iolair said that the developer already owns a copy. That doesn't seem like a good reason for migrating.
I'll argue in favour of SQL Server over DBFs any day of the week, but if the application is working OK, and there are no serious database-related issues, why change?
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
Olaf Doschke
Programmer
Why change? Because it would be the first move towards a new frontend anyway.
If the software as is is working and does not need any improvments and changes in the future, then you of course stay with what you had. But that is out of question, I think.
From my experince I see users always have ideas on how things could be improved, laws sometimes also are asking for changes of a software. To stay means to end at some point in the future.
It doesn't hurt to give data migration a try and make first steps and experience with sql server on the one side, while staying with the app as is on the other side.
Bye, Olaf.
If the software as is is working and does not need any improvments and changes in the future, then you of course stay with what you had. But that is out of question, I think.
From my experince I see users always have ideas on how things could be improved, laws sometimes also are asking for changes of a software. To stay means to end at some point in the future.
It doesn't hurt to give data migration a try and make first steps and experience with sql server on the one side, while staying with the app as is on the other side.
Bye, Olaf.
Mike Lewis
Programmer
But the only question that he asked was whether to upgrade from VFP 8.0 to 9.0. He never mentioned a new front end, or even a change of back end.
I'm not saying the application will never need updating. As you say, Olaf, there will always be a need for changes or new features. But that's a long way from saying he needs to switch to a different database.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
I'm not saying the application will never need updating. As you say, Olaf, there will always be a need for changes or new features. But that's a long way from saying he needs to switch to a different database.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
Olaf Doschke
Programmer
Well, yes, but that was the drift the thread has. Because when asking to update vfp8->9 the question is why then to vfp9 and why not to skip that step and move forward to mssql.
Of course staying also is an option in the first place. Depends on what is to do at the moment and if there is spare time for learning something new. In the end you will never get around it, so why not start now?
Bye, Olaf.
Of course staying also is an option in the first place. Depends on what is to do at the moment and if there is spare time for learning something new. In the end you will never get around it, so why not start now?
Bye, Olaf.
olaf , tx for info on sedna upsize improvements. I've used the bulk xml method and it is very effective to pick out all sorts of things that vfp tends to 'tolerate' but sql-server not. Will do a comparison using upsizer on some typical tables of 400,000 plus records and post results back here. Clean data migration is a first step and also a good time to re-think the data relations a bit.
fyi , tested the sedna upsizer , works 100% !!
1) outputs reserved sql words in brckets e.g. [proc] for a vfp field called proc , you would then just re-name / refactor to e.g. ReqProcess in the sql table
2)logs conversion errors e.g.
Connectivity error: [Microsoft][SQL Server Native Client 10.0][SQL Server]The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value.
3)speed is fine , it actually uses the same xml bulk load method as referred to earlier as the upload method
when complete, you can then do any refactor that you want e.g. rename req_no to RequisitionNumber etc to keep some key fields more in line with sql naming conventions
1) outputs reserved sql words in brckets e.g. [proc] for a vfp field called proc , you would then just re-name / refactor to e.g. ReqProcess in the sql table
2)logs conversion errors e.g.
Connectivity error: [Microsoft][SQL Server Native Client 10.0][SQL Server]The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value.
3)speed is fine , it actually uses the same xml bulk load method as referred to earlier as the upload method
when complete, you can then do any refactor that you want e.g. rename req_no to RequisitionNumber etc to keep some key fields more in line with sql naming conventions
Olaf Doschke
Programmer
In regard to XMLBulkload: That it was used in the new upsizing wizard version a bit later after his post might be the reason Doug mentioned it with a "sly grin".
Bye, Olaf.
Bye, Olaf.
- Thread starter
- #31
To clear things up a bit, yes, things are working in VFP now. And will continue for a while, but since there will be no new VFP, and we don't know if it will work ten years from now on Windows 21, or whatever version it is, we are planning a "migration". From what we can tell, Microsoft is going to SQL Server and Visual Studio. That is why we bought them, to start the process.
Just looking to the future, and trying to predict what will happen <g>.......
Iolair MacWalter
Network Engineer
Just looking to the future, and trying to predict what will happen <g>.......
Iolair MacWalter
Network Engineer
Mike Lewis
Programmer
Iolair,
That makes perfect sense. Thanks for the clarification. (Although I'm not sure what you mean by "Microsoft is going to SQL Server and Visual Studio". Surely, Microsoft went that way many years ago. But never mind.)
Having said that, I wouldn't back any current technology today on the basis that it will still be around for Windows 21 - or even Windows 9. But that's just my biased personal view.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
That makes perfect sense. Thanks for the clarification. (Although I'm not sure what you mean by "Microsoft is going to SQL Server and Visual Studio". Surely, Microsoft went that way many years ago. But never mind.)
Having said that, I wouldn't back any current technology today on the basis that it will still be around for Windows 21 - or even Windows 9. But that's just my biased personal view.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
ain't broke , don't fix , sure , but ...
if you don't have some kind of vfp migration plan , you will soon be broke
personally , I would see most of the apps I do still working in 5 years time ; but there are a few where there is a high level of IT awareness . To these , I will be saying to them " you should be migrating from vfp to sql over the next 2/3 years" and saying to myself " look forward to yacht in bermuda when I bill you "
if you don't have some kind of vfp migration plan , you will soon be broke
personally , I would see most of the apps I do still working in 5 years time ; but there are a few where there is a high level of IT awareness . To these , I will be saying to them " you should be migrating from vfp to sql over the next 2/3 years" and saying to myself " look forward to yacht in bermuda when I bill you "
- Thread starter
- #35
I will be saying to them "you should be migrating from vfp to sql over the next 2/3 years"
When I hear broad statements like this from others it affects me like fingernails across a blackboard.
As a result I continually respond by saying that "You are not stating the issue correctly!!!"
In most cases, the VFP part of the application involves BOTH the application development language and the data 'backend"
While the suggested SQL part of things CANNOT address both parts.
It can only address one part of the issue - the application's data 'backend'.
So the broad statement above is meaningless and not applicable - as stated.
Yes, migrating the application's data 'backend' to a SQL Server is a good path towards the future that I too recommend often.
BUT, as stated in the original statement, that does not address whether or not the Application (and the language it is developed in) should also be migrated (and SQL cannot do the job!!!).
If you are going to suggest changing from VFP (and there might be a number of good and/or not-so-good reasons to do so) then don't expect SQL to do it all for you.
Good Luck,
JRB-Bldr
When I hear broad statements like this from others it affects me like fingernails across a blackboard.
As a result I continually respond by saying that "You are not stating the issue correctly!!!"
In most cases, the VFP part of the application involves BOTH the application development language and the data 'backend"
While the suggested SQL part of things CANNOT address both parts.
It can only address one part of the issue - the application's data 'backend'.
So the broad statement above is meaningless and not applicable - as stated.
Yes, migrating the application's data 'backend' to a SQL Server is a good path towards the future that I too recommend often.
BUT, as stated in the original statement, that does not address whether or not the Application (and the language it is developed in) should also be migrated (and SQL cannot do the job!!!).
If you are going to suggest changing from VFP (and there might be a number of good and/or not-so-good reasons to do so) then don't expect SQL to do it all for you.
Good Luck,
JRB-Bldr
we are all agreed that existing vfp apps can still be chugging away merrily in 10 years time , but I believe it is also a good idea to have some migration plans for 'some' clients,especially any that have IT 'policies'. To me , that is a positive development.
"migrating from vfp to sql" was just meant as a pretty loose term , certainly would not reccomend scratching nails across blackboards.
Of course the front end also has to move to dotNet, and this in turn requires some choices
1) winforms vs wpf , cannot see any reason to even consider Silverlight ; my vote winforms , for many reasons
2) c# vs vb , c# for many reasons
3) ORM ( entity , nHibernate etc) vs 'data-binding' ; my vote data-binding
4) typed v. untyped ; always typed datasets
5) 3rd party cntrols or not ? devexpress etc , not sure
6) cost/time estimates ; comparable features take a lot longer to code in dotNet
7) etc etc etc
"migrating from vfp to sql" was just meant as a pretty loose term , certainly would not reccomend scratching nails across blackboards.
Of course the front end also has to move to dotNet, and this in turn requires some choices
1) winforms vs wpf , cannot see any reason to even consider Silverlight ; my vote winforms , for many reasons
2) c# vs vb , c# for many reasons
3) ORM ( entity , nHibernate etc) vs 'data-binding' ; my vote data-binding
4) typed v. untyped ; always typed datasets
5) 3rd party cntrols or not ? devexpress etc , not sure
6) cost/time estimates ; comparable features take a lot longer to code in dotNet
7) etc etc etc
- Status
Similar threads
