If X# supports less than 100% VFP syntax, then you'll probably need an "adapter" to spot places where some manual changes are needed.

That's what we've done with FoxInCloud (http://foxincloud.com/download.php) where some instructions need a manual adaptation (eg. moving code to a callback method, reports).

Based on experience, VFP having almost 40 years of history, all possible syntax variations are used; even some hidden features (https://support.west-wind.com/Thread5LH04TJKZ.wwt).

Partial support also requires a migration, without a possible back step: a decision always difficult for large applications, unless you can migrate block by block.

>Hi Thomas,
>
>Again, I think we pre-empt. All these will be supported in some way or the other. I for one was quite pessimistic that VFP CLASS definitions can be handled by the X# compiler, and voila in 2 months time we have a compiler that is probably 95% + complete...
>
>Lets hear the impressions of Tore Bleken, Cecil C, Eric Selje, Matt Slay after the post conference session next week Sunday, which they all will be attending...
>
>Johan
>
>>Linq is already supported in both Linq and Lambda format:
>Linq is not SQL even if the syntax is more recognizable than in most other, more ORM leaning ways.
>Impedance Mismatch creeps in, although MUCH less - but you are probably giving MS-SQL server a definite gain, as I am certain Datadapter for that backend will get more love and polish compared to Postgres, SQLite or others.
>
>NOT saying it SQL Server is a bad product (actually IMO it dukes it out with Postgres for #1 if Windows as OS is given) - and I am not a MS hater - (I reserve badmouthing developer for Oracle when using Java) but I'd rather not streamline all my SW to the whims of MS, as they are whimsical...
>
>Vfp has 2 techniques to act as a smart database client: Remote Views (designed mid-90ies! - brilliant, prophetic stuff at that time!) and CursorAdapter - modeled after Dotnet DataAdapter, using established cursor engine instead of DataSet.
>It spits out basic CRUD usable with almost any relational backend.
>
>>Regarding in memory "SQLite", I am busy looking at converting the following ArrayServer class from Visual Objects to X#. The DevTeam has indicated after SWFOX the VFP Cursor will get priority, this might be the basis of it realising...:
>
>My guess is that without full xSharp-SQL interface to Dbf-Tables more than half of remaining vfp devs will stay away from xSharp. Perhaps by at first using Advantage local server while finishing own stuff - Advantage is x86/x64 only, and most benefit will be on mobile devices, so it must wander into portable runtime, not depend on drivers for ODBC or even COM-ADO. I realize that RDD is something I currently cannot visualize fully - must think about the options gained there more.
>But even if the ArrayCursor is faster than vfp - without the SQL integration of local DBF and "anyXSharpCursor" in the same SQL Join too much of the Fox DNA is lost for me.
>
>The problems/worries I read about on xSharp and those few other Clipper/(x)Harbour/Vulcan.Net/VO/Fivewin boards about "moving to SQL" (I try to do a bit "due diligence" before jumping in) are almost nonexistant if you heeded any talks/sessions on n-tier dev and switchable data sources held since the late nineties. I used MVVM and onion principle before the term was defined, as it "just made sense" compared to MVC. So why not implement SQL, Cursors, Data Sessions and Buffering on dbf first, then check if speed needs a boost, measure .Net-Datasets and the go for Array-based memory if some cursors need a boost ?
>
>>
>>> Hope my post was clear enough. Language design is not my thing!
>>Loud and clear
>
>Language design also not my prediliction - but I search in all languages for the "special sauce". In vfp it is data integration - from language to tables, using tables everywhere in own tools (reports, GUI datasture, Profiler...) connecting to any relational backend out there.
>
>Hope I did not come on too strong - I do like the enthusiasm of that small group trying for xSharp. But I also was burned twice - with Etecnologica I grew sceptical early on, later invested about a year in Lianja (Which is a good product with a near-genius developer, no slight on the stuff they build or the responsiveness on bugs found - just that they decided to concentrate on the backend side for biz layer as well and too much for my taste) only to have the roadmap changed and mobile embedded database was scrapped for good.
>
>As xSharp Source is available, I can tweak and help if the DNA is there or at least actively targeted, but if it is "just xBase syntax" without that fox-data integration it makes more sense for me to move again into bigger ponds (Java or Javascript, sadly no Python market) and try to recreate such layer in minimalist form there - less effort to sell myself, more time for such fun.