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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
fact finding question VFP9 & MSSQL 2016
- Thread starter Goofus828
- Start date
Olaf Doschke
Programmer
Any version of MSSQL can add other data via linked server or import it using an SSIS package and defining an OleDB source with the OleDB provider, that's valid for any other DBMS, not only DBFs.
If the question is about any new feature of native (Foxpro) DBF file access this would be news to me, but I don't think that would be integrated into the list of sources for SSIS and surely I see no reason, why T-SQL would be extended with commands acting on DBFs. T-SQL is concerned about SQL Server databases and the only other aspects of other file types are either flat files or backup files. CLR integration also opens some doors, but that's just due to whatever .NET Framework features are used. I don't see any reason, why the core database engine would be expanded to direct native DBF access.
One more aspect is also older and happened even before VFP was phased out as product, MSSQL Server had the new data type date introduced in 2008 (AFAIR, but surely in 2008R2). This definitely happend at least in parallel to VFPs retirement plans and when you consider both had to be planned earlier than announcement or release, the decision might have been made to allow for easier data transfer from DBF to MSSQL databases to be able to transfer data without much conversion and adaption troubles. But otherwise, I see no merging in of the DBF SQL engine into T-SQL, which hasn't been done long before. To continue that thought I would go off topic now about the end of VFP, I spare that part and just conclude, there is no native aspect of DBF file handling more than for any other third party database. Still, only flat files have a special role aside of native SQL tables and remote data. Other file types only are added outside the core SQL Server DB engine, eg SSMS allows you to easily take a result and store it as excel file, but that is a feature of the studio, not of the sql engine. And as I already said CLR integration also opens many doors, but not for core db engine T-SQL code. The integration into CLR Stored Procs make that even tighter, but still a separate thing, as CLR also isn't directly having native DBF handling inside, this also goes through ODBC or OleDB.
Bye, Olaf.
If the question is about any new feature of native (Foxpro) DBF file access this would be news to me, but I don't think that would be integrated into the list of sources for SSIS and surely I see no reason, why T-SQL would be extended with commands acting on DBFs. T-SQL is concerned about SQL Server databases and the only other aspects of other file types are either flat files or backup files. CLR integration also opens some doors, but that's just due to whatever .NET Framework features are used. I don't see any reason, why the core database engine would be expanded to direct native DBF access.
One more aspect is also older and happened even before VFP was phased out as product, MSSQL Server had the new data type date introduced in 2008 (AFAIR, but surely in 2008R2). This definitely happend at least in parallel to VFPs retirement plans and when you consider both had to be planned earlier than announcement or release, the decision might have been made to allow for easier data transfer from DBF to MSSQL databases to be able to transfer data without much conversion and adaption troubles. But otherwise, I see no merging in of the DBF SQL engine into T-SQL, which hasn't been done long before. To continue that thought I would go off topic now about the end of VFP, I spare that part and just conclude, there is no native aspect of DBF file handling more than for any other third party database. Still, only flat files have a special role aside of native SQL tables and remote data. Other file types only are added outside the core SQL Server DB engine, eg SSMS allows you to easily take a result and store it as excel file, but that is a feature of the studio, not of the sql engine. And as I already said CLR integration also opens many doors, but not for core db engine T-SQL code. The integration into CLR Stored Procs make that even tighter, but still a separate thing, as CLR also isn't directly having native DBF handling inside, this also goes through ODBC or OleDB.
Bye, Olaf.
Mike Lewis
Programmer
And, of course, VFP can read and write (and create and delete) SQL Server tables (given suitable components, such as an ODBC driver).
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
- Thread starter
- #4
Mike Lewis
Programmer
.
Just out of curiosity, was the interviewer asking this question to test your knowledge, or did he genuinely want to know the answer? And what did you answer him?
I don't mean to pry, so don't answer if you prefer not to (and I won't ask if you go the job).
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
- Status
Similar threads
- Question
