Yuri:

I think we are talking about somewhat different things here. I know that you can manipulate data through OLEDB provider, and I realize that you actually can run VFP EXESCRIPT from .NET. Interesting idea, if a bit brute force!

However, this approach STILL relies on VFP runtimes working on Windows. As long as that is the case, why not just use the "real" VFP to begin with?

What the VFP .NET compiler attempts to do is lift the entire VFP syntax out of VFP and onto .NET without ANY further reliance on ANY Microsoft VFP components whatsoever. No runtimes, no nothing. Furthermore, the VFP .NET compiler does away with a bunch of current VFP limitations, like the 2GB file size. Of course, if your file grows that big, you would be well advised to move it to a more robust backend anyway, such as MySQL or Postgres or Firebird, to begin with. Right-o, I on purpose did not list the MS SQL server here because I'm still smarting from the latest MS move regarding VFP and hence, to future-proof myself, I try to move towards open source as much as possible -- which, of course .NET isn't, but it is the only platform with at least a budding high VFP compatibility option in the works. (So, call me a hypocrite, see if I care! Besides, if .NET was yanked -- unlikely! -- there would definitely be some option to move out of that platform to another, because of the huge userbase would certainly lead to a compatible system from some other compatny) i digress.. my original pint was that with this option if you WANT to to shoot yourself in the foot with xBase files over 2GB, at least you CAN.

And then there's the fact that the .NET compiler opens up the entire .NET CLR to your app, because it compiles into a 100% .NET intermediate language. So, if this comes to pass successfully, you can then transform your VFP applications into .NET without TOO much sweat, and rest assured that your application's environment won't croak with the next Windows version. And once the transformation is done, you can start extending your applications with all the cool stuff in .NET. If you want. But if you don't care, you don't HAVE to.


And all of this is much, much different than simply firing EXECSCRIPT from your VB.NET application.


Pertti

>Pertti,
>
>I doubt that including VFP syntax/language into NET application code is a good idea until MS does not provide VFP integrating into NET package.
>
>In any case, you may not need to do anything: in NET you may use ADO with VFP OLEDB provider. It allows you to call a lot of VFP functions, create VFP cursors, it supports many of the VFP native tools for data manipulations, etc. Even more, it allows you to Execute the entire foxpro.prg as is. Here is one of my exercises written in VB.NET:
>
>

>........
>cnnVFP = CreateObject("ADODB.Connection")
>cnnVFP.Open("Provider=VFPOLEDB.1;Data Source=" + VFPDirectory + ";Collating Sequence=MACHINE")
>
>*'format foxpro prg text, prepare the proper vfp EXECSCRIPT call, and call it via ADO Execute.
>
>ofso = CreateObject("Scripting.FileSystemObject")
>With ofso.OpenTextFile("vfpcode.prg")
>           lctmpstr = .readall
>           .close()
>End With
>ctmpstr = "EXECSCRIPT('" + lctmpstr + "', '" + VFPDirectory + "', '" + _
>                    lctmp1 + "', '" + lctmp2 + "')"
>lctmpstr = lctmpstr.Replace(Chr(13) + Chr(10), "' +CHR(13)+CHR(10)+'")
>
>cnnVFP.Execute(lctmpstr)
>.......
>
>

>
>
>Just my 2 cents.