Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Run Visual FoxPro apps in .Net
Message
From
11/01/2007 11:27:49
 
General information
Forum:
Visual FoxPro
Category:
Visual FoxPro and .NET
Environment versions
Visual FoxPro:
VFP 9
OS:
Windows XP SP2
Network:
Windows 2003 Server
Database:
MS SQL Server
Miscellaneous
Thread ID:
01183814
Message ID:
01184617
Views:
27
Hi Samuel,

thanks for your quick and detailed response. I did take an even longer look, downloaded and will test when I have free time... Some of the points got another answer inline, others I deleted as the points are clear.

>?? Are you planning to support vfp functions as well (your site literally speaks only about "command coberage")
>Answer: Try the online compiler you'll see a lot of VFP Functions already implemented.

Yes, that is a good way to verify everything. But a potential customer might want to get a quick overview before testing if anything necessary for him is working as expected. Having unit-testcode close by (yes, I looked at the examples in the now working links) makes for easier testing: for me an approach like the example.dbf in the Sample\WinAPI directory gives a great overview and shows me code to compare (which might be more necessary in C), but help in your case to demonstrate the effects/syntax of strongly typed variables.

>>?? make a similar separate list for SQL compatibility with vfp (especially when using the exabyte layer <bg>)
>Answer: Well, for this we want full compatibility with VFP, so there should not be differences.

Good target. But in case of reaching slightly less than 100%, give examples of the differences you are currently aware of. If I know beforehand you are still struggling with a certain feature, I will try to program around it. A readable bug/issue list stops some understandable worries about using new products.


>>?? how about ball park figures for intended price range, licensing model and release targets with disclaimer ?
>Answer: Still planning this, will let you know later.

Fair enough. I looked at the license info in your help file. Personal opinion: Don't use arbitrary number like 2 installations allowed. Make a personal or machine license: the machine license installs info under "all users", the personal installation has license info installed for each role I need to work with it on the machine - I can understand if I have to install twice on the same machine if I need the license under admin role as well.

Setting the limit to 2 machines might make me think about quick deinstall and reinstall on another machine when needed, or installing to a USB stick and carrying that around... And what if one machine croaks and I cannot deinstall before sending it to repairs ? I'ld be going against the exact wording while keeping inside the spirit of the license.

OTOH a larger shop might want to buy just the number of licenses needed for all the machines the developers share. Just my personal 2 cents.

>Amswer: we are using other engine for the exabyte layer but this does not seem an issue for the SQL parser.

So I might have to remember some twists which work/optimize better using the exabyte layer but I get an engine already tested and verified in actual use for some time. Sounds like a good compromise.

>>??? publishing your benchmark code will be a great way to build trust.
>Answer: Well compile this code and let us know. Trick: use memory variables, because the VFP layer trip is slow in the Alpha. You do a VFP layer trip when you wrote ? lnend instead of ? m.lnEnd.
...
>TLOCAL xInfo as System::IO::FileInfo
>Gives you strong typing if you want it. If not
>LOCAL xInfo
>Works like usual but of couse slower.

Will use some code I recently had to recode as fll as problem did not fit vfp language/variable implementation well.

>> ? This way at first I don't have to veryfy every step, only the things routines working on the exa tables.
>Answer: We think the same way so we first introduce .NET Extender and later the VFPCompiler and we already are using both in the way you figured out.

I have to show some clairvoyance to keep my image up <g>.


>Answer: Well, the 2 gig limit is so small for today multimedia apps, this is one reason we broke it. It seems to us overkill to use a Database Server for only storing big blobs, for that it is better a Table Layer like the one on VFP.

The next border is probably reccount()>2**31, as you would need record pointers larger than 4 byte in the cdx for instance. Can the Exabyte layer handle more than 2**31 records ? How far have you pushed the keylength limits of the cdx, to target another vfp limit probably widened a bit ?

regards

thomas
Previous
Reply
Map
View

Click here to load this message in the networking platform