Dear Rick,
I have many projects developed with VFP 9 and West Wind Web Connection.
I would like to come out from VFP limits, specially Maximum size of a table file (2 Gb).
I could to migrate to SQL or MySql, but projects are bigs and full of VFP native commands, so it would require a lot of rewriting.
Please what solution do you suggest to me?
Many thanks for support
VFP Advanced 10.1 overcomes the 2 GB limitation:
2, For Large Files, there is no any changes for the dbf, fpt and cdx files structure.
Maximum size of a file: 2048 TB.
Maximum # of records per table file: 1 billion (same as VFP 9.0).
Maximum size of a table file (or cursor): 1 billion * RECSIZE(), if RECSIZE()=65500 (maximum), it is 65 TB.
Maximum block of an FPT file: 2 billion.
Maximum size of an FPT file: 2 billion * SET("BLOCKSIZE"), if SET("BLOCKSIZE")=64 (default setting), it is 128 GB.
Maximum size of an index file: 4 GB (double of VFP 9.0).
Hi Thierry,
17 days ago I asked here "is WC fully compatible with VFP Advanced 10 64-bit?"
but Rick replied "No idea and it's not a design goal."
This is why I have still looking for a solution.
Thank you very much for support
Your best solution is to split the big tables into smaller ones. I have done it myself, and it's far easier than you might think, not that much code.
If you use no activeX, VFPA 64 only requires a re-compilation; you can very easily give it a try, especially for COM object.
Hi Tore,
I have several tables, so I have to look everywhere in projects to double search functions.
I am afraid it penalizes performances.
Hi Thierry,
did you tried VFPA with Web Connection?
Many thanks
Search for all your DBF's and other tables, and see which of them are close to reach the maximum size. Then adapt your application for these tables only. Shouldn't be that hard. And the speed difference will hardly be noticeable.
Be realistic, what other options do you have? Hoping for a miracle that won't happen?
A re-write to use a separate SQL server will take you several years. My cure will be much quicker and easier.
No, YOU can be the pioneer on that
You are right, I will try VFPA and your solution will be the second chance 😃
That's fine. I'm sure many people will be happy to hear the results, please keep us updated.
Luca,
If VFPA is 'just recompile' and it so easy - why don't you try it and see for yourself... and if it works great as is, there won't be anything else to do.
I've not heard of anybody doing it, and I would think that somebody must have tried this since Web Connection apps are pretty wide spread and would be a primary candidate for the 64 bit improvements. Given that we haven't heard anything I'm going to guess it didn't work.
My philosophy is simple: if it requires specific changes in Web Connection, you have your answer as to why I don't want to support this in the first place. If does work - well then you don't need anything special.
Web Connection does quite a bit of stuff that requires custom 32 bit DLLs, COM, etc. that if something is going to fail with VFPA it likely will.
The last thing I want to deal with is having to support an unsupported platform here. FoxPro has enough quirks and incorrect behaviors of its own without adding the craziness of an unauthorized third party recompiling the source code from decompiled binaries.
Is that really worth it to you? All for potentially getting greater than 2gb data files? (which frankly if you have data that size shouldn't be in FoxPro tables in the first place).
I'd consider what Tore said about other solutions:
- Using a different data source (some SQL engine)
- Breaking up data into multiple smaller sub-sets
+++ Rick ---
Luca,
If VFPA is 'just recompile' and it so easy - why don't you try it and see for yourself... and if it works great as is, there won't be anything else to do.
I've not heard of anybody doing it, and I would think that somebody must have tried this since Web Connection apps are pretty wide spread and would be a primary candidate for the 64 bit improvements.
My philosophy is simple: if it requires specific changes in Web Connection, you have your answer as to why I don't want to support this in the first place. If does work - well then you don't need anything special.
Web Connection does quite a bit of stuff that requires custom 32 bit DLLs, COM, etc. that if something is going to fail with VFPA it likely will.
The last thing I want to deal with is having to support an unsupported platform here. FoxPro has enough quirks and incorrect behaviors of its own without adding the craziness of an unauthorized third party recompiling the source code from decompiled binaries.
Is that really worth it to you? All for potentially getting greater than 2gb data files? (which frankly if you have data that size shouldn't be in FoxPro tables in the first place).
I'd consider what Tore said about other solutions:
- Using a different data source (some SQL engine)
- Breaking up data into multiple smaller sub-sets
+++ Rick ---
As Rick indicates, trying to run WC under 64-bit VFPA is problematic because of the dependency on 32-bit libraries. However, you don't have to go the 64-bit route since VFPA 32-bit also claims to support large files.
I think there's a lot better chance that the VFPA solution will work if you keep everything in 32-bits. I've seen demos showing trivial VFP 9 apps that were compiled and successfully run under VFPA. Whether that carries over to something with the complexity of the WC framework is another question, but it wouldn't take a lot of effort to download the product and try it.
--stein
Rick,
Replies seem to bounce and created twice.
Your reply to Luca is addressed to me.
That may have just been my mistake clicking on reply on the wrong message in this thread 😄
+++ Rick ---
Dear friends,
I buyed FoxPro 10.1 Advanced 32-bit, installed on developing computer without difficulties and tested immediately creating a 4,55 Gb table with 4 APPEND FROM commands.
On the contrary, I cannot open the new table with FoxPro 9.
I am testing web Connection applications with FoxPro 10.1 and still everything is alright.
In weekend I will update the customer server.
I repeat what I wrote in another forum: As you have noticed, switching to VFP10 is a one way train. There's no way back. And very few to help you if you run into something.
I would never have taken that risk without very thorough and solid tests over a long period.
You are right, in fact I'm in no hurry, the biggest tables in database are 1 Gb now.