Hi all
I think I have come across a possibly undocumented limitation to the maximum number of expressions in a CALCULATE command. In my case a fatal error occurred when trying to CALCULATE the SUMs of 32 different fields in a cursor. It took a while to establish what was going on, but when I reduced the number of expressions to 31 the error no longer occurred.
Has anybody else encountered this issue? Many thanks
Paul Newton
Interesting. I whipped up this test and cannot replicate the problem: CREATE CURSOR crsTest (id i) cCmd = [CALCULATE ] FOR x = 1 TO 32 cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCmd = cCmd + "SUM("+cField+")," NEXT cCmd = cCmd + "AVG(Field1)" &cCmd
On Thu, Nov 21, 2019 at 9:50 AM Paul Newton Paul.Newton@pegasus.co.uk wrote:
Hi all
I think I have come across a possibly undocumented limitation to the maximum number of expressions in a CALCULATE command. In my case a fatal error occurred when trying to CALCULATE the SUMs of 32 different fields in a cursor. It took a while to establish what was going on, but when I reduced the number of expressions to 31 the error no longer occurred.
Has anybody else encountered this issue? Many thanks
Paul Newton
[excessive quoting removed by server]
Hi Eric I think that's because the limit is 32 (not 31 as I stated). Try using For x = 1 To 33 and I think you will get the problem. Please let us know Thanks Paul Newton
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Eric Selje Sent: 21 November 2019 16:17 To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
Sent by an external sender ------------------------------
Interesting. I whipped up this test and cannot replicate the problem: CREATE CURSOR crsTest (id i) cCmd = [CALCULATE ] FOR x = 1 TO 32 cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCmd = cCmd + "SUM("+cField+")," NEXT cCmd = cCmd + "AVG(Field1)" &cCmd
On Thu, Nov 21, 2019 at 9:50 AM Paul Newton Paul.Newton@pegasus.co.uk wrote:
Hi all
I think I have come across a possibly undocumented limitation to the maximum number of expressions in a CALCULATE command. In my case a fatal error occurred when trying to CALCULATE the SUMs of 32 different fields in a cursor. It took a while to establish what was going on, but when I reduced the number of expressions to 31 the error no longer occurred.
Has anybody else encountered this issue? Many thanks
Paul Newton
[excessive quoting removed by server]
Paul, There is no data in the cursor he created. How many records are you SUMming?
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Paul Newton Sent: Thursday, November 21, 2019 11:29 AM To: profoxtech@leafe.com Subject: RE: Fatal error issuing CALCULATE command
Hi Eric I think that's because the limit is 32 (not 31 as I stated). Try using For x = 1 To 33 and I think you will get the problem. Please let us know Thanks Paul Newton
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Eric Selje Sent: 21 November 2019 16:17 To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
Sent by an external sender ------------------------------
Interesting. I whipped up this test and cannot replicate the problem: CREATE CURSOR crsTest (id i) cCmd = [CALCULATE ] FOR x = 1 TO 32 cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCmd = cCmd + "SUM("+cField+")," NEXT cCmd = cCmd + "AVG(Field1)" &cCmd
On Thu, Nov 21, 2019 at 9:50 AM Paul Newton Paul.Newton@pegasus.co.uk wrote:
Hi all
I think I have come across a possibly undocumented limitation to the maximum number of expressions in a CALCULATE command. In my case a fatal error occurred when trying to CALCULATE the SUMs of 32 different fields in a cursor. It took a while to establish what was going on, but when I reduced the number of expressions to 31 the error no longer
occurred.
Has anybody else encountered this issue? Many thanks
Paul Newton
[excessive quoting removed by server]
This tweak adds rows so there's something to actually calculate. I tried it with many variations on fields and rows and cannot get it to crash.
#DEFINE _fields 35 #DEFINE _rows 100 =RAND(-1) CREATE CURSOR crsTest (id i) cCalcCmd = [CALCULATE ] cInsertFields = [] cInsertValues = [] FOR x = 1 TO _fields cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCalcCmd = cCalcCmd + "SUM("+cField+")," cInsertFields = cInsertFields + ","+cField cInsertValues = cInsertValues + ","+TRANS(INT(RAND()*100)) NEXT cInsertCmd = [INSERT INTO crsTest (ID ] + cInsertFields +[) VALUES (0]+cInsertValues+')' FOR X = 1 TO _rows &cInsertCmd NEXT cCalcCmd = cCalcCmd + "AVG(Field1)" &cCalcCmd
On Thu, Nov 21, 2019 at 11:37 AM Tracy Pearson tracy@powerchurch.com wrote:
Paul, There is no data in the cursor he created. How many records are you SUMming?
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Paul Newton Sent: Thursday, November 21, 2019 11:29 AM To: profoxtech@leafe.com Subject: RE: Fatal error issuing CALCULATE command
Hi Eric I think that's because the limit is 32 (not 31 as I stated). Try using For x = 1 To 33 and I think you will get the problem. Please let us know Thanks Paul Newton
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Eric Selje Sent: 21 November 2019 16:17 To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
Sent by an external sender
Interesting. I whipped up this test and cannot replicate the problem: CREATE CURSOR crsTest (id i) cCmd = [CALCULATE ] FOR x = 1 TO 32 cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCmd = cCmd + "SUM("+cField+")," NEXT cCmd = cCmd + "AVG(Field1)" &cCmd
On Thu, Nov 21, 2019 at 9:50 AM Paul Newton Paul.Newton@pegasus.co.uk wrote:
Hi all
I think I have come across a possibly undocumented limitation to the maximum number of expressions in a CALCULATE command. In my case a fatal error occurred when trying to CALCULATE the SUMs of 32 different fields in a cursor. It took a while to establish what was going on, but when I reduced the number of expressions to 31 the error no longer
occurred.
Has anybody else encountered this issue? Many thanks
Paul Newton
[excessive quoting removed by server]
Eric,
Now, is that in VFP 9 SP 2, or VFP Advanced?
Tracu
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Eric Selje Sent: Thursday, November 21, 2019 12:59 PM To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
This tweak adds rows so there's something to actually calculate. I tried it with many variations on fields and rows and cannot get it to crash.
#DEFINE _fields 35 #DEFINE _rows 100 =RAND(-1) CREATE CURSOR crsTest (id i) cCalcCmd = [CALCULATE ] cInsertFields = [] cInsertValues = [] FOR x = 1 TO _fields cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCalcCmd = cCalcCmd + "SUM("+cField+")," cInsertFields = cInsertFields + ","+cField cInsertValues = cInsertValues + ","+TRANS(INT(RAND()*100)) NEXT cInsertCmd = [INSERT INTO crsTest (ID ] + cInsertFields +[) VALUES (0]+cInsertValues+')' FOR X = 1 TO _rows &cInsertCmd NEXT cCalcCmd = cCalcCmd + "AVG(Field1)" &cCalcCmd
On Thu, Nov 21, 2019 at 11:37 AM Tracy Pearson tracy@powerchurch.com wrote:
Paul, There is no data in the cursor he created. How many records are you SUMming?
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Paul Newton Sent: Thursday, November 21, 2019 11:29 AM To: profoxtech@leafe.com Subject: RE: Fatal error issuing CALCULATE command
Hi Eric I think that's because the limit is 32 (not 31 as I stated). Try using
For
x = 1 To 33 and I think you will get the problem. Please let us know Thanks Paul Newton
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Eric Selje Sent: 21 November 2019 16:17 To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
Sent by an external sender
Interesting. I whipped up this test and cannot replicate the problem: CREATE CURSOR crsTest (id i) cCmd = [CALCULATE ] FOR x = 1 TO 32 cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCmd = cCmd + "SUM("+cField+")," NEXT cCmd = cCmd + "AVG(Field1)" &cCmd
On Thu, Nov 21, 2019 at 9:50 AM Paul Newton Paul.Newton@pegasus.co.uk wrote:
Hi all
I think I have come across a possibly undocumented limitation to the maximum number of expressions in a CALCULATE command. In my case a fatal error occurred when trying to CALCULATE the SUMs of 32 different fields in a cursor. It took a while to establish what was going on, but when I reduced the number of expressions to 31 the error no longer
occurred.
Has anybody else encountered this issue? Many thanks
Paul Newton
[excessive quoting removed by server]
Fair question. That's VFP9. I was going to try it in VFPA if it failed in VFP9 to see if that fixed the issue but since it didn't fail I haven't bothered.
Update: It works fine in VFPA too.
On Thu, Nov 21, 2019 at 12:04 PM Tracy Pearson tracy@powerchurch.com wrote:
Eric,
Now, is that in VFP 9 SP 2, or VFP Advanced?
Tracu
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Eric Selje Sent: Thursday, November 21, 2019 12:59 PM To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
This tweak adds rows so there's something to actually calculate. I tried it with many variations on fields and rows and cannot get it to crash.
#DEFINE _fields 35 #DEFINE _rows 100 =RAND(-1) CREATE CURSOR crsTest (id i) cCalcCmd = [CALCULATE ] cInsertFields = [] cInsertValues = [] FOR x = 1 TO _fields cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCalcCmd = cCalcCmd + "SUM("+cField+")," cInsertFields = cInsertFields + ","+cField cInsertValues = cInsertValues + ","+TRANS(INT(RAND()*100)) NEXT cInsertCmd = [INSERT INTO crsTest (ID ] + cInsertFields +[) VALUES (0]+cInsertValues+')' FOR X = 1 TO _rows &cInsertCmd NEXT cCalcCmd = cCalcCmd + "AVG(Field1)" &cCalcCmd
On Thu, Nov 21, 2019 at 11:37 AM Tracy Pearson tracy@powerchurch.com wrote:
Paul, There is no data in the cursor he created. How many records are you SUMming?
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Paul Newton Sent: Thursday, November 21, 2019 11:29 AM To: profoxtech@leafe.com Subject: RE: Fatal error issuing CALCULATE command
Hi Eric I think that's because the limit is 32 (not 31 as I stated). Try using
For
x = 1 To 33 and I think you will get the problem. Please let us know Thanks Paul Newton
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Eric Selje Sent: 21 November 2019 16:17 To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
Sent by an external sender
Interesting. I whipped up this test and cannot replicate the problem: CREATE CURSOR crsTest (id i) cCmd = [CALCULATE ] FOR x = 1 TO 32 cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCmd = cCmd + "SUM("+cField+")," NEXT cCmd = cCmd + "AVG(Field1)" &cCmd
On Thu, Nov 21, 2019 at 9:50 AM Paul Newton Paul.Newton@pegasus.co.uk wrote:
Hi all
I think I have come across a possibly undocumented limitation to the maximum number of expressions in a CALCULATE command. In my case a fatal error occurred when trying to CALCULATE the SUMs of 32 different fields in a cursor. It took a while to establish what was going on, but when I reduced the number of expressions to 31 the error no longer
occurred.
Has anybody else encountered this issue? Many thanks
Paul Newton
[excessive quoting removed by server]
-------- Forwarded Message --------
Subject:
RE: Fatal error issuing CALCULATE command
Date:
Thu, 21 Nov 2019 13:04:20 -0500
From:
Tracy Pearson tracy@powerchurch.com
Reply-To:
ProFox Email List profox@leafe.com
To:
profox@leafe.com
Eric,
Now, is that in VFP 9 SP 2, or VFP Advanced?
Is Anybody using "VFP Advanced" here? IIRC, that's the Chinese VFP 10 version for 64-bit...correct?
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
VFP 10 (or VFP Advanced) is a copy of your licensed copy of VFP9, with some binary patches to fix bugs and add features. There's *also* a 64-bit version.
Yes, I use it every day, along with 1000's of others. My opinion is that there's no reason every VFP developer should not.
Eric
On Thu, Nov 21, 2019 at 1:43 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 11/21/2019 2:42 PM, MB Software Solutions, LLC wrote:
Is Anybody using "VFP Advanced" here? IIRC, that's the Chinese VFP 10 version for 64-bit...correct?
(Anybody other than Eric, I mean.)
[excessive quoting removed by server]
On 11/21/2019 2:54 PM, Eric Selje wrote:
VFP 10 (or VFP Advanced) is a copy of your licensed copy of VFP9, with some binary patches to fix bugs and add features. There's *also* a 64-bit version.
Yes, I use it every day, along with 1000's of others. My opinion is that there's no reason every VFP developer should not.
Eric
Cool. So it's basically a new set of runtimes and you just redistribute those with your apps? What's the VERSION() value returned?
On 11/21/2019 2:54 PM, Eric Selje wrote:
VFP 10 (or VFP Advanced) is a copy of your licensed copy of VFP9, with some binary patches to fix bugs and add features. There's *also* a 64-bit version.
Yes, I use it every day, along with 1000's of others. My opinion is that there's no reason every VFP developer should not.
Eric
I was surprised that M$ didn't send out a "cease and desist" or some such action for it. Morally and ethically, there's nothing wrong with it from what I can tell, but you recall the HUGE STINK they put up when Whil Hentzen was going to show VFP running on WINE. I can't see the harm in that either, for that matter. If that increases M$'s VFP sales, GREAT! (Yes, that's laughable to say...cue the quote by BG about every time VFP was sold, they lost $20,000 or something on SQL Server sales.)
The Microsoft of 20 years ago probably would have complained, but they're a different company now. Their take is basically "If you want to modify the copy of VFP that you paid for, go for it."
VERSION() either returns 10, or not. Almost all of the changes he implemented can be turned off with settings for maximum backwards compatibility.
On Thu, Nov 21, 2019 at 2:07 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 11/21/2019 2:54 PM, Eric Selje wrote:
VFP 10 (or VFP Advanced) is a copy of your licensed copy of VFP9, with
some
binary patches to fix bugs and add features. There's *also* a 64-bit version.
Yes, I use it every day, along with 1000's of others. My opinion is that there's no reason every VFP developer should not.
Eric
I was surprised that M$ didn't send out a "cease and desist" or some such action for it. Morally and ethically, there's nothing wrong with it from what I can tell, but you recall the HUGE STINK they put up when Whil Hentzen was going to show VFP running on WINE. I can't see the harm in that either, for that matter. If that increases M$'s VFP sales, GREAT! (Yes, that's laughable to say...cue the quote by BG about every time VFP was sold, they lost $20,000 or something on SQL Server sales.)
[excessive quoting removed by server]
This is going to seem like a stupid question I'm sure but is there a way to run VFPA (either 32 or 64 bit) in parallel with VFP9?
I'd like to test, but I don't want to mess up my existing development environment. Some of the readme files seem to indicate the answer is no.
Paul H. Tarver
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Eric Selje Sent: Thursday, November 21, 2019 3:35 PM To: profoxtech@leafe.com Subject: Re: VFP Advanced (was Fwd: RE: Fatal error issuing CALCULATE command)
The Microsoft of 20 years ago probably would have complained, but they're a different company now. Their take is basically "If you want to modify the copy of VFP that you paid for, go for it."
VERSION() either returns 10, or not. Almost all of the changes he implemented can be turned off with settings for maximum backwards compatibility.
On Thu, Nov 21, 2019 at 2:07 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 11/21/2019 2:54 PM, Eric Selje wrote:
VFP 10 (or VFP Advanced) is a copy of your licensed copy of VFP9, with
some
binary patches to fix bugs and add features. There's *also* a 64-bit version.
Yes, I use it every day, along with 1000's of others. My opinion is that there's no reason every VFP developer should not.
Eric
I was surprised that M$ didn't send out a "cease and desist" or some such action for it. Morally and ethically, there's nothing wrong with it from what I can tell, but you recall the HUGE STINK they put up when Whil Hentzen was going to show VFP running on WINE. I can't see the harm in that either, for that matter. If that increases M$'s VFP sales, GREAT! (Yes, that's laughable to say...cue the quote by BG about every time VFP was sold, they lost $20,000 or something on SQL Server sales.)
[excessive quoting removed by server]
On 11/21/2019 5:09 PM, Paul H. Tarver wrote:
This is going to seem like a stupid question I'm sure but is there a way to run VFPA (either 32 or 64 bit) in parallel with VFP9?
I'd like to test, but I don't want to mess up my existing development environment. Some of the readme files seem to indicate the answer is no.
Paul H. Tarver
Time for that 2nd laptop (Or Virtual Machine), Paul.
Actually, I have a virtual machine I could do that on, I was just thinking it would be easier to do side-by-side comparisons. One thing is certain, doing the first install on a virtual machine is definitely probably the way to start as the instructions are a bit vague. :)
Paul H. Tarver
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of MB Software Solutions, LLC Sent: Thursday, November 21, 2019 5:05 PM To: profoxtech@leafe.com Subject: Re: VFP Advanced (was Fwd: RE: Fatal error issuing CALCULATE command)
On 11/21/2019 5:09 PM, Paul H. Tarver wrote:
This is going to seem like a stupid question I'm sure but is there a way
to
run VFPA (either 32 or 64 bit) in parallel with VFP9?
I'd like to test, but I don't want to mess up my existing development environment. Some of the readme files seem to indicate the answer is no.
Paul H. Tarver
Time for that 2nd laptop (Or Virtual Machine), Paul.
[excessive quoting removed by server]
Hi Paul,
You missed Eric's SWFox presentation. You can have VFP 9 SP 2, VFP Advanced, and VFP Advanced 64bit running on the same machine. Eric didn't say you needed to change anything. Here did have both VFP 9 and Advanced running at the same time.
Tracy
On November 21, 2019 5:09:27 PM EST, "Paul H. Tarver" paul@tpcqpc.com wrote:
This is going to seem like a stupid question I'm sure but is there a way to run VFPA (either 32 or 64 bit) in parallel with VFP9?
I'd like to test, but I don't want to mess up my existing development environment. Some of the readme files seem to indicate the answer is no.
Paul H. Tarver
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Eric Selje Sent: Thursday, November 21, 2019 3:35 PM To: profoxtech@leafe.com Subject: Re: VFP Advanced (was Fwd: RE: Fatal error issuing CALCULATE command)
The Microsoft of 20 years ago probably would have complained, but they're a different company now. Their take is basically "If you want to modify the copy of VFP that you paid for, go for it."
VERSION() either returns 10, or not. Almost all of the changes he implemented can be turned off with settings for maximum backwards compatibility.
On Thu, Nov 21, 2019 at 2:07 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 11/21/2019 2:54 PM, Eric Selje wrote:
VFP 10 (or VFP Advanced) is a copy of your licensed copy of VFP9,
with
some
binary patches to fix bugs and add features. There's *also* a
64-bit
version.
Yes, I use it every day, along with 1000's of others. My opinion is
that
there's no reason every VFP developer should not.
Eric
I was surprised that M$ didn't send out a "cease and desist" or some such action for it. Morally and ethically, there's nothing wrong
with
it from what I can tell, but you recall the HUGE STINK they put up
when
Whil Hentzen was going to show VFP running on WINE. I can't see the harm in that either, for that matter. If that increases M$'s VFP
sales,
GREAT! (Yes, that's laughable to say...cue the quote by BG about
every
time VFP was sold, they lost $20,000 or something on SQL Server
sales.)
[excessive quoting removed by server]
Yep, they don't mess with each other at all unless you have VFPA take over your file extensions for .app files, etc.
On Thu, Nov 21, 2019 at 7:24 PM Tracy Pearson tracy@powerchurch.com wrote:
Hi Paul,
You missed Eric's SWFox presentation. You can have VFP 9 SP 2, VFP Advanced, and VFP Advanced 64bit running on the same machine. Eric didn't say you needed to change anything. Here did have both VFP 9 and Advanced running at the same time.
Tracy
On November 21, 2019 5:09:27 PM EST, "Paul H. Tarver" paul@tpcqpc.com wrote:
This is going to seem like a stupid question I'm sure but is there a way to run VFPA (either 32 or 64 bit) in parallel with VFP9?
I'd like to test, but I don't want to mess up my existing development environment. Some of the readme files seem to indicate the answer is no.
Paul H. Tarver
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Eric Selje Sent: Thursday, November 21, 2019 3:35 PM To: profoxtech@leafe.com Subject: Re: VFP Advanced (was Fwd: RE: Fatal error issuing CALCULATE command)
The Microsoft of 20 years ago probably would have complained, but they're a different company now. Their take is basically "If you want to modify the copy of VFP that you paid for, go for it."
VERSION() either returns 10, or not. Almost all of the changes he implemented can be turned off with settings for maximum backwards compatibility.
On Thu, Nov 21, 2019 at 2:07 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 11/21/2019 2:54 PM, Eric Selje wrote:
VFP 10 (or VFP Advanced) is a copy of your licensed copy of VFP9,
with
some
binary patches to fix bugs and add features. There's *also* a
64-bit
version.
Yes, I use it every day, along with 1000's of others. My opinion is
that
there's no reason every VFP developer should not.
Eric
I was surprised that M$ didn't send out a "cease and desist" or some such action for it. Morally and ethically, there's nothing wrong
with
it from what I can tell, but you recall the HUGE STINK they put up
when
Whil Hentzen was going to show VFP running on WINE. I can't see the harm in that either, for that matter. If that increases M$'s VFP
sales,
GREAT! (Yes, that's laughable to say...cue the quote by BG about
every
time VFP was sold, they lost $20,000 or something on SQL Server
sales.)
[excessive quoting removed by server]
Dang it!
Paul H. Tarver
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Tracy Pearson Sent: Thursday, November 21, 2019 7:24 PM To: profoxtech@leafe.com Subject: RE: VFP Advanced (was Fwd: RE: Fatal error issuing CALCULATE command)
Hi Paul,
You missed Eric's SWFox presentation. You can have VFP 9 SP 2, VFP Advanced, and VFP Advanced 64bit running on the same machine. Eric didn't say you needed to change anything. Here did have both VFP 9 and Advanced running at the same time.
Tracy
On November 21, 2019 5:09:27 PM EST, "Paul H. Tarver" paul@tpcqpc.com wrote:
This is going to seem like a stupid question I'm sure but is there a way to run VFPA (either 32 or 64 bit) in parallel with VFP9?
I'd like to test, but I don't want to mess up my existing development environment. Some of the readme files seem to indicate the answer is no.
Paul H. Tarver
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Eric Selje Sent: Thursday, November 21, 2019 3:35 PM To: profoxtech@leafe.com Subject: Re: VFP Advanced (was Fwd: RE: Fatal error issuing CALCULATE command)
The Microsoft of 20 years ago probably would have complained, but they're a different company now. Their take is basically "If you want to modify the copy of VFP that you paid for, go for it."
VERSION() either returns 10, or not. Almost all of the changes he implemented can be turned off with settings for maximum backwards compatibility.
On Thu, Nov 21, 2019 at 2:07 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 11/21/2019 2:54 PM, Eric Selje wrote:
VFP 10 (or VFP Advanced) is a copy of your licensed copy of VFP9,
with
some
binary patches to fix bugs and add features. There's *also* a
64-bit
version.
Yes, I use it every day, along with 1000's of others. My opinion is
that
there's no reason every VFP developer should not.
Eric
I was surprised that M$ didn't send out a "cease and desist" or some such action for it. Morally and ethically, there's nothing wrong
with
it from what I can tell, but you recall the HUGE STINK they put up
when
Whil Hentzen was going to show VFP running on WINE. I can't see the harm in that either, for that matter. If that increases M$'s VFP
sales,
GREAT! (Yes, that's laughable to say...cue the quote by BG about
every
time VFP was sold, they lost $20,000 or something on SQL Server
sales.)
[excessive quoting removed by server]
Apparently, I've been under a rock, and there's a magically enhanced VFP9 SP2 that fixes some bugs, can run concurrently with vfp9, and supports 64 bits.
Before I download something, am I on the right site: http://baiyujia.com/vfpadvanced/f_vfpa_about.asp ?
Thanks!
Yes, that is the right site.
Happy Coding! Tracy
On November 22, 2019 10:42:56 PM EST, Vince Teachout vinny@caracal.net wrote:
Apparently, I've been under a rock, and there's a magically enhanced VFP9 SP2 that fixes some bugs, can run concurrently with vfp9, and supports 64 bits.
Before I download something, am I on the right site: http://baiyujia.com/vfpadvanced/f_vfpa_about.asp ?
Thanks!
Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/ce5a8b3d-d308-5d78-eeb7-1c92e4e1d1b4@caraca... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Report [OT] Abuse: http://leafe.com/reportAbuse/ce5a8b3d-d308-5d78-eeb7-1c92e4e1d1b4@caracal.ne...
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
So do we just keep developing as we were but put the VFPA runtime files in place (and deploy them to client sites)? No real change for our development?
On 11/22/2019 11:08 PM, Tracy Pearson wrote:
Yes, that is the right site.
Happy Coding! Tracy
On November 22, 2019 10:42:56 PM EST, Vince Teachout vinny@caracal.net wrote:
Apparently, I've been under a rock, and there's a magically enhanced VFP9 SP2 that fixes some bugs, can run concurrently with vfp9, and supports 64 bits.
Before I download something, am I on the right site: http://baiyujia.com/vfpadvanced/f_vfpa_about.asp ?
Thanks!
Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/ce5a8b3d-d308-5d78-eeb7-1c92e4e1d1b4@caraca... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Report [OT] Abuse: http://leafe.com/reportAbuse/ce5a8b3d-d308-5d78-eeb7-1c92e4e1d1b4@caracal.ne...
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]
Yes that is one solution. You van also install VFPA in a separate directory, not in the same as VFP9. One can than decide to construct the pjx either in VFP9 or VFPA. Deployment of an exe built under VFPA: mr. Chen published a document How-to-Do Rgds Koen
Op za 23 nov. 2019 om 12:32 schreef MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com>
So do we just keep developing as we were but put the VFPA runtime files in place (and deploy them to client sites)? No real change for our development?
On 11/22/2019 11:08 PM, Tracy Pearson wrote:
Yes, that is the right site.
Happy Coding! Tracy
On November 22, 2019 10:42:56 PM EST, Vince Teachout vinny@caracal.net
wrote:
Apparently, I've been under a rock, and there's a magically enhanced VFP9 SP2 that fixes some bugs, can run concurrently with vfp9, and supports 64 bits.
Before I download something, am I on the right site: http://baiyujia.com/vfpadvanced/f_vfpa_about.asp ?
Thanks!
Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message:
https://leafe.com/archives/byMID/ce5a8b3d-d308-5d78-eeb7-1c92e4e1d1b4@caraca...
** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Report [OT] Abuse:
http://leafe.com/reportAbuse/ce5a8b3d-d308-5d78-eeb7-1c92e4e1d1b4@caracal.ne...
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]
If you want to download a Chinese hacked version of Visual Foxpro, yep.
I dont think one can call this a hacked version. I would call it an enhanced version. Given the fact of all the bugs mr Chen corrected in VFP9SP2 Koen
Op ma 25 nov. 2019 om 15:32 schreef Alan Bourke alanpbourke@fastmail.fm
If you want to download a Chinese hacked version of Visual Foxpro, yep.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
As I already wrote it: No, you don't download a hacked version of VFP9. You download a patcher, which copies your already installed VFP9 into a new directory, and then patches the various bugs. All patches are documented, and you could easily do a diff on the original and the patched version.
Sometimes it would help to get off that Trump-level paranoia :)
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von Alan Bourke Gesendet: Montag, 25. November 2019 15:32 An: profoxtech@leafe.com Betreff: Re: So, about this VFPA thing...
If you want to download a Chinese hacked version of Visual Foxpro, yep.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
*my motto of the day: *Those who insist that VFPA is a hacked version of VFP9 have no knowledge of Visual FoxPro.
Koen
Op ma 25 nov. 2019 om 18:36 schreef Jürgen Wondzinski <juergen@wondzinski.de
:
As I already wrote it: No, you don't download a hacked version of VFP9. You download a patcher, which copies your already installed VFP9 into a new directory, and then patches the various bugs. All patches are documented, and you could easily do a diff on the original and the patched version.
Sometimes it would help to get off that Trump-level paranoia :)
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von Alan Bourke Gesendet: Montag, 25. November 2019 15:32 An: profoxtech@leafe.com Betreff: Re: So, about this VFPA thing...
If you want to download a Chinese hacked version of Visual Foxpro, yep.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
On Mon, 25 Nov 2019, at 5:39 PM, Koen Piller wrote:
*my motto of the day: *Those who insist that VFPA is a hacked version of VFP9 have no knowledge of Visual FoxPro.
I've been working with FoxPro since 1991, so spare me your motto. This thing alters the binaries, and is therefore a hack in the classic sense of the term. Having said that I'm sure it's all fine and legit, if anyone wants to take a gamble on it.
On 11/26/2019 4:26 AM, Alan Bourke wrote:
On Mon, 25 Nov 2019, at 5:39 PM, Koen Piller wrote:
*my motto of the day: *Those who insist that VFPA is a hacked version of VFP9 have no knowledge of Visual FoxPro.
I've been working with FoxPro since 1991, so spare me your motto. This thing alters the binaries, and is therefore a hack in the classic sense of the term. Having said that I'm sure it's all fine and legit, if anyone wants to take a gamble on it.
Yeah, Koen...Alan's been here a long time and is well respected. Any alteration as he says is truly a "hack" but the mere words are not meant to convey anything nefarious or illegal (although I restate my surprise at M$ not objecting...but as we said, it's not the ballmer era anymore).
OK alright. My first impression on Alan's remark was a negative, meaning negative in the sense of the product, like this product is a hack, it is no good to use. Now meanwhile I have looked around and found on Wiki an explication of 'hack' :* Hacking is finding applications that are not intended by the creator of the resource, especially with regard to computers. Complexity does not play a role here, on the contrary, easy and fast alternative solutions are preferred. The use of a clothes peg to prevent a trouser leg from coming between a bicycle chain is basically a hack. "Normal" inventions and improvements are therefore not hacks, as long as they are used for what they are made for.* This makes me think Alan is not correct and I conclude VFPA is an improvement. Besides, the history of Alan's use: since 1991, I am proud to tell you I was there before 1990, started with dBaseII jumped from dBaseIV to FoxPro for DOS into now VFP9SP2. Regards, Koen
Op di 26 nov. 2019 om 16:32 schreef MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com>:
On 11/26/2019 4:26 AM, Alan Bourke wrote:
On Mon, 25 Nov 2019, at 5:39 PM, Koen Piller wrote:
*my motto of the day: *Those who insist that VFPA is a hacked version of VFP9 have no knowledge of Visual FoxPro.
I've been working with FoxPro since 1991, so spare me your motto. This
thing alters the binaries, and is therefore a hack in the classic sense of the term. Having said that I'm sure it's all fine and legit, if anyone wants to take a gamble on it.
Yeah, Koen...Alan's been here a long time and is well respected. Any alteration as he says is truly a "hack" but the mere words are not meant to convey anything nefarious or illegal (although I restate my surprise at M$ not objecting...but as we said, it's not the ballmer era anymore).
[excessive quoting removed by server]
Think i started with foxbase
On Tue, Nov 26, 2019 at 5:07 PM Koen Piller koen.piller@gmail.com wrote:
OK alright. My first impression on Alan's remark was a negative, meaning negative in the sense of the product, like this product is a hack, it is no good to use. Now meanwhile I have looked around and found on Wiki an explication of 'hack' :* Hacking is finding applications that are not intended by the creator of the resource, especially with regard to computers. Complexity does not play a role here, on the contrary, easy and fast alternative solutions are preferred. The use of a clothes peg to prevent a trouser leg from coming between a bicycle chain is basically a hack. "Normal" inventions and improvements are therefore not hacks, as long as they are used for what they are made for.* This makes me think Alan is not correct and I conclude VFPA is an improvement. Besides, the history of Alan's use: since 1991, I am proud to tell you I was there before 1990, started with dBaseII jumped from dBaseIV to FoxPro for DOS into now VFP9SP2. Regards, Koen
Op di 26 nov. 2019 om 16:32 schreef MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com>:
On 11/26/2019 4:26 AM, Alan Bourke wrote:
On Mon, 25 Nov 2019, at 5:39 PM, Koen Piller wrote:
*my motto of the day: *Those who insist that VFPA is a hacked version of VFP9 have no knowledge of Visual FoxPro.
I've been working with FoxPro since 1991, so spare me your motto. This
thing alters the binaries, and is therefore a hack in the classic sense
of
the term. Having said that I'm sure it's all fine and legit, if anyone wants to take a gamble on it.
Yeah, Koen...Alan's been here a long time and is well respected. Any alteration as he says is truly a "hack" but the mere words are not meant to convey anything nefarious or illegal (although I restate my surprise at M$ not objecting...but as we said, it's not the ballmer era anymore).
[excessive quoting removed by server]
Technically, what VPA is doing is actually not intended by its owner, MS. So I think the term hack does apply. If it were an open source tool, then I would say it would not be a hack. Like others have said, the work 'hack' draws out negative connotations (for us developers). But consider other terms we hear like "Life hacks" that offer creative ways of using products for unexpected things.
But hack or not, all the points are valid. Someone modified binaries which we usually do not look at and which we probably would have a very hard time analyzing (since we do not have the source code of VFP itself). Also, folks have been using it without any reported incident of suspicious behavior. All it would take is one substantiated, repeatable report and that news would spread rapidly.
And having worked for the gov, I have to add the usual paranoia regarding foreign entities creating something I would build on - especially if that something deals with "data". But again, here, this is not a foreign government providing something, it is an individual. Could his government storm his house, and take over his work? Sure, it's China - it's gov does that kind of thing - most communist nations do (our gov might do it in the future if we don't pay attention). But again, such things would probably get out quickly. Maybe he should work out a fail-safe, dead-man trigger or something so that we would know if such an event transpired. <g>
Anyway, it is definitely interesting enough that I plan on working with it. I would love larger DBF capacities too, but I will not quibble. The guy is doing some amazing stuff. I hope he reaps big rewards from it somehow.
-Charlie
On Tue, Nov 26, 2019 at 11:07 AM Koen Piller koen.piller@gmail.com wrote:
OK alright. My first impression on Alan's remark was a negative, meaning negative in the sense of the product, like this product is a hack, it is no good to use. Now meanwhile I have looked around and found on Wiki an explication of 'hack' :* Hacking is finding applications that are not intended by the creator of the resource, especially with regard to computers. Complexity does not play a role here, on the contrary, easy and fast alternative solutions are preferred. The use of a clothes peg to prevent a trouser leg from coming between a bicycle chain is basically a hack. "Normal" inventions and improvements are therefore not hacks, as long as they are used for what they are made for.* This makes me think Alan is not correct and I conclude VFPA is an improvement. Besides, the history of Alan's use: since 1991, I am proud to tell you I was there before 1990, started with dBaseII jumped from dBaseIV to FoxPro for DOS into now VFP9SP2. Regards, Koen
Op di 26 nov. 2019 om 16:32 schreef MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com>:
On 11/26/2019 4:26 AM, Alan Bourke wrote:
On Mon, 25 Nov 2019, at 5:39 PM, Koen Piller wrote:
*my motto of the day: *Those who insist that VFPA is a hacked version of VFP9 have no knowledge of Visual FoxPro.
I've been working with FoxPro since 1991, so spare me your motto. This
thing alters the binaries, and is therefore a hack in the classic sense
of
the term. Having said that I'm sure it's all fine and legit, if anyone wants to take a gamble on it.
Yeah, Koen...Alan's been here a long time and is well respected. Any alteration as he says is truly a "hack" but the mere words are not meant to convey anything nefarious or illegal (although I restate my surprise at M$ not objecting...but as we said, it's not the ballmer era anymore).
[excessive quoting removed by server]
On 11/26/2019 12:32 PM, Charlie Coleman wrote:
Technically, what VPA is doing is actually not intended by its owner, MS.
...which is why I was surprised M$ did nothing to stop it.
Anyway, it is definitely interesting enough that I plan on working with it. I would love larger DBF capacities too, but I will not quibble. The guy is doing some amazing stuff. I hope he reaps big rewards from it somehow.
Wait...does it allow the 2GB ceiling per file (DBF, CDX, FPT, etc.) to be lifted? I missed that if so. ???
The 2Gb limitation is in the DBF structure. DBFs and CDX could grow into Terabytes without problems. It's just that good old dBase has decided to set the maximum filesize to 2Gb (which was the max harddisk size at that time).
You may have heard about "Advantage Database Server", originally from Extended Systems, later on acquired by Sybase, later on acquired by SAP. That ADS server is based on DBFs as internal datastructure. They have two modes: VFP compatible (then you can add a true MultiTier Server on top of your existing DBC/DBF/CDX), and the extended version, which alters the DBF-header (and renames them to ADT) and is then limited at only disksize (or 2 billion records at 65k each = 6.55e+16 tablesize)
I once spoke with one of the developers of Extended Systems, why they stil use the DBF file structure. He told me that the VFP tables and indices are stil the fastest ISAM based structure, and together with their own SQL engine based on top of that (they also have their own Rushmore-like optimizer) they are stil faster than traditional better-known Dataservers. Unfortunately, MS prohibits publishing of speedtests in their license, but one should think why SAP has acquired them...
For more info: https://www.sap.com/products/advantage-database-server.html
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von MB Software Solutions, LLC Gesendet: Dienstag, 26. November 2019 19:31 An: profox@leafe.com Betreff: Re: So, about this VFPA thing...
On 11/26/2019 12:32 PM, Charlie Coleman wrote:
Technically, what VPA is doing is actually not intended by its owner, MS.
...which is why I was surprised M$ did nothing to stop it.
Anyway, it is definitely interesting enough that I plan on working with it. I would love larger DBF capacities too, but I will not quibble. The guy is doing some amazing stuff. I hope he reaps big rewards from it somehow.
Wait...does it allow the 2GB ceiling per file (DBF, CDX, FPT, etc.) to be lifted? I missed that if so. ???
[excessive quoting removed by server]
Charlie,
To respond to your wish for larger DBF capacities. Out at SWFox, the guys from X# explained the limitation isn't in VFP, it's in the header of the DBF. To change the header, means no VFP 9 tools will be able to use the table. (OLEDB and ODBC included)
I like the idea, I haven't been given permission to work with VFPA at the office yet.
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Charlie Coleman Sent: Tuesday, November 26, 2019 12:33 PM To: profoxtech@leafe.com Subject: Re: So, about this VFPA thing...
Technically, what VPA is doing is actually not intended by its owner, MS. So I think the term hack does apply. If it were an open source tool, then I would say it would not be a hack. Like others have said, the work 'hack' draws out negative connotations (for us developers). But consider other terms we hear like "Life hacks" that offer creative ways of using products for unexpected things.
But hack or not, all the points are valid. Someone modified binaries which we usually do not look at and which we probably would have a very hard time analyzing (since we do not have the source code of VFP itself). Also, folks have been using it without any reported incident of suspicious behavior. All it would take is one substantiated, repeatable report and that news would spread rapidly.
And having worked for the gov, I have to add the usual paranoia regarding foreign entities creating something I would build on - especially if that something deals with "data". But again, here, this is not a foreign government providing something, it is an individual. Could his government storm his house, and take over his work? Sure, it's China - it's gov does that kind of thing - most communist nations do (our gov might do it in the future if we don't pay attention). But again, such things would probably get out quickly. Maybe he should work out a fail-safe, dead-man trigger or something so that we would know if such an event transpired. <g>
Anyway, it is definitely interesting enough that I plan on working with it. I would love larger DBF capacities too, but I will not quibble. The guy is doing some amazing stuff. I hope he reaps big rewards from it somehow.
-Charlie
On Tue, Nov 26, 2019 at 11:07 AM Koen Piller koen.piller@gmail.com wrote:
OK alright. My first impression on Alan's remark was a negative, meaning negative in the sense of the product, like this product is a hack, it is
no
good to use. Now meanwhile I have looked around and found on Wiki an explication of 'hack' :* Hacking is finding applications that are not intended by the creator of the resource, especially with regard to computers. Complexity does not play a role here, on the contrary, easy and fast alternative solutions are preferred. The use of a clothes peg to prevent a trouser leg from coming between a bicycle chain is basically a hack. "Normal" inventions and improvements are therefore not hacks, as
long
as they are used for what they are made for.* This makes me think Alan is not correct and I conclude VFPA is an improvement. Besides, the history of Alan's use: since 1991, I am proud to tell you I was there before 1990, started with dBaseII jumped from dBaseIV to FoxPro for DOS into now VFP9SP2. Regards, Koen
Op di 26 nov. 2019 om 16:32 schreef MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com>:
On 11/26/2019 4:26 AM, Alan Bourke wrote:
On Mon, 25 Nov 2019, at 5:39 PM, Koen Piller wrote:
*my motto of the day: *Those who insist that VFPA is a hacked version of VFP9 have no knowledge of Visual FoxPro.
I've been working with FoxPro since 1991, so spare me your motto. This
thing alters the binaries, and is therefore a hack in the classic sense
of
the term. Having said that I'm sure it's all fine and legit, if anyone wants to take a gamble on it.
Yeah, Koen...Alan's been here a long time and is well respected. Any alteration as he says is truly a "hack" but the mere words are not meant to convey anything nefarious or illegal (although I restate my surprise at M$ not objecting...but as we said, it's not the ballmer era anymore).
[excessive quoting removed by server]
On Tue, 26 Nov 2019, at 6:51 PM, Tracy Pearson wrote:
Charlie,
To respond to your wish for larger DBF capacities.
There's also Advantage Database Server (now owned by SAP) which lets you work with DBF\CDX\FPT over 4GB.
On 11/27/2019 3:47 AM, Alan Bourke wrote:
On Tue, 26 Nov 2019, at 6:51 PM, Tracy Pearson wrote:
Charlie,
To respond to your wish for larger DBF capacities.
There's also Advantage Database Server (now owned by SAP) which lets you work with DBF\CDX\FPT over 4GB.
Ever since I switched to MySQL (and later MariaDB) back in 2004, I've never wanted to go back to DBFs for major app tables. Never.
For me, I've done kind of the opposite. In other words, I'll connect to a SQL DB, Postgres, Oracle, whatever, download the whole database to VFP, read info from the information_schema stuff, recreate indexes, etc. Then work with the data in the local VFP DB for analysis and so forth.
So it's not really the complete opposite because the real prod database is not 'moved' to VFP. It is just there for analysis, tests, and so on. I found the speed and flexibility the VFP DB gives me trumps what I get from the DB Servers. Of course that is a generalization and a major factor here is the 'locality' of access. Also, there are the cases where I am not the DBA of the prod database which makes working with VFP an even better option (I can index, restructure, freely based on what I'm trying to figure out).
And I fully understand the reasons behind the individual "file size" limitations of DBFs, DBCs, etc. It really was not disk space or stuff like that, it was how many bytes to use for "addressing" - and back at the time of FoxBase, etc, I think the 32bit integer was about the largest available. I have wondered though if there are ways to use the 'extra bytes' in the DBF header to expand the address space. The idea being that older tools would only be able to access the "first" 2GB of data, but newer tools could be written to look at the other bytes and switch to 64bit numbers to go further. Anyway, no biggie. It is simple enough to split data into multiple tables based on some value in the data. And then stored procedures or other code easily "calculates" which table(s) to pull based on a query using that value.
And as a quick side note about the 'temporary cursor' thing that I used instead of MS's approach to table/record buffering... Once I started using it, built a few code classes around it, I never wanted to use the standard buffering options again. And I never ran into the odd 'table-header-lock' stuff or whatever it was that folks sometimes hit with MS's buffering options. The thing I liked best was I got very fine-grained control of the logic of "buffering" and how to resolve conflicts. I had a truly separate "data set" that i could analyze 6 ways to Sunday against the original data, even compare who was locking what, "pause" updates with specific messages, and son on. Was that needed for every project - nope. But I did need it a couple times. Well, 'need' may be an overstatement - I'll just say what the client wanted was not feasible with the standard buffering approaches as far as I could figure out.
-Charlie
On Wed, Nov 27, 2019 at 9:17 AM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 11/27/2019 3:47 AM, Alan Bourke wrote:
On Tue, 26 Nov 2019, at 6:51 PM, Tracy Pearson wrote:
Charlie,
To respond to your wish for larger DBF capacities.
There's also Advantage Database Server (now owned by SAP) which lets you
work with DBF\CDX\FPT over 4GB.
Ever since I switched to MySQL (and later MariaDB) back in 2004, I've never wanted to go back to DBFs for major app tables. Never.
[excessive quoting removed by server]
Agreed 1000% that using local data for reporting is fastest in VFP apps, for sure. I had written some code awhile (back but didn't yet finish) that would pull data locally if the checksum of the MariaDB table had changed, and then I'd using the max(timestamp) field on the local VFP table to grab all records updated since then on the MariaDB table (using its timestamp field too, which was automatically updated as data changed). One day I'll get back to it...when no other payable work to do. ;-)
On 11/27/2019 12:12 PM, Charlie Coleman wrote:
For me, I've done kind of the opposite. In other words, I'll connect to a SQL DB, Postgres, Oracle, whatever, download the whole database to VFP, read info from the information_schema stuff, recreate indexes, etc. Then work with the data in the local VFP DB for analysis and so forth.
So it's not really the complete opposite because the real prod database is not 'moved' to VFP. It is just there for analysis, tests, and so on. I found the speed and flexibility the VFP DB gives me trumps what I get from the DB Servers. Of course that is a generalization and a major factor here is the 'locality' of access. Also, there are the cases where I am not the DBA of the prod database which makes working with VFP an even better option (I can index, restructure, freely based on what I'm trying to figure out).
And I fully understand the reasons behind the individual "file size" limitations of DBFs, DBCs, etc. It really was not disk space or stuff like that, it was how many bytes to use for "addressing" - and back at the time of FoxBase, etc, I think the 32bit integer was about the largest available. I have wondered though if there are ways to use the 'extra bytes' in the DBF header to expand the address space. The idea being that older tools would only be able to access the "first" 2GB of data, but newer tools could be written to look at the other bytes and switch to 64bit numbers to go further. Anyway, no biggie. It is simple enough to split data into multiple tables based on some value in the data. And then stored procedures or other code easily "calculates" which table(s) to pull based on a query using that value.
And as a quick side note about the 'temporary cursor' thing that I used instead of MS's approach to table/record buffering... Once I started using it, built a few code classes around it, I never wanted to use the standard buffering options again. And I never ran into the odd 'table-header-lock' stuff or whatever it was that folks sometimes hit with MS's buffering options. The thing I liked best was I got very fine-grained control of the logic of "buffering" and how to resolve conflicts. I had a truly separate "data set" that i could analyze 6 ways to Sunday against the original data, even compare who was locking what, "pause" updates with specific messages, and son on. Was that needed for every project - nope. But I did need it a couple times. Well, 'need' may be an overstatement - I'll just say what the client wanted was not feasible with the standard buffering approaches as far as I could figure out.
-Charlie
On Wed, Nov 27, 2019 at 9:17 AM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 11/27/2019 3:47 AM, Alan Bourke wrote:
On Tue, 26 Nov 2019, at 6:51 PM, Tracy Pearson wrote:
Charlie,
To respond to your wish for larger DBF capacities.
There's also Advantage Database Server (now owned by SAP) which lets you
work with DBF\CDX\FPT over 4GB.
Ever since I switched to MySQL (and later MariaDB) back in 2004, I've never wanted to go back to DBFs for major app tables. Never.
[excessive quoting removed by server]
DBFs aren't unstable. In contrary they are one of the most stable storage options we have. Simple structure, easy to read and write, fast access. As long as you use them locally, there's no better engine. And that's why ADS is stil using them: they have a pure local access with their C/S engine. What made them problematic and bad-mouthed are the classic multiuser network problems, with a real file-access and data-transport over cable or WLAN you are always prone to problems. Thus, it would be better to state: For local data manipulation / massage / extraction, VFP and DBFs are stil king; and for MultiUser you better use any kind of C/S.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von MB Software Solutions, LLC Gesendet: Mittwoch, 27. November 2019 15:17 An: profox@leafe.com Betreff: Re: So, about this VFPA thing...
On 11/27/2019 3:47 AM, Alan Bourke wrote:
On Tue, 26 Nov 2019, at 6:51 PM, Tracy Pearson wrote:
Charlie,
To respond to your wish for larger DBF capacities.
There's also Advantage Database Server (now owned by SAP) which lets you
work with DBF\CDX\FPT over 4GB.
Ever since I switched to MySQL (and later MariaDB) back in 2004, I've never wanted to go back to DBFs for major app tables. Never.
[excessive quoting removed by server]
Well that's very fair to say, yes, I agree wOOdy. The very few problems I had over the years with VFP DBFs were caused by operating system issues.
On 11/28/2019 4:21 AM, Jürgen Wondzinski wrote:
DBFs aren't unstable. In contrary they are one of the most stable storage options we have. Simple structure, easy to read and write, fast access. As long as you use them locally, there's no better engine. And that's why ADS is stil using them: they have a pure local access with their C/S engine. What made them problematic and bad-mouthed are the classic multiuser network problems, with a real file-access and data-transport over cable or WLAN you are always prone to problems. Thus, it would be better to state: For local data manipulation / massage / extraction, VFP and DBFs are stil king; and for MultiUser you better use any kind of C/S.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von MB Software Solutions, LLC Gesendet: Mittwoch, 27. November 2019 15:17 An: profox@leafe.com Betreff: Re: So, about this VFPA thing...
On 11/27/2019 3:47 AM, Alan Bourke wrote:
On Tue, 26 Nov 2019, at 6:51 PM, Tracy Pearson wrote:
Charlie,
To respond to your wish for larger DBF capacities.
There's also Advantage Database Server (now owned by SAP) which lets you
work with DBF\CDX\FPT over 4GB.
Ever since I switched to MySQL (and later MariaDB) back in 2004, I've never wanted to go back to DBFs for major app tables. Never.
[excessive quoting removed by server]
The reason why MS doesn't care about VFPA is simple. For example in Germany we have a law, that the user is allowed to fix bugs by himself, if the vendor is not willing to do so. Similar law seems to exist in USA ("Right to repair act"). If MS would go against it, they would have to fix those bugs, which is contrary to their habits.
On 25/11/2019 17:36, Jürgen Wondzinski wrote:
Sometimes it would help to get off that Trump-level paranoia :)
wOOdy
"Just because you are paranoid doesn't mean Trump isn't out to get you" ;-)
Peter
This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR. Tel:0161 831 3700 Fax:0161 831 3715
London Office: 101 St. Martin's Lane,London, WC2N 4AZ Tel:0207 299 7960
On 11/26/2019 7:20 AM, Peter Cushing wrote:
On 25/11/2019 17:36, Jürgen Wondzinski wrote:
Sometimes it would help to get off that Trump-level paranoia :)
wOOdy
"Just because you are paranoid doesn't mean Trump isn't out to get you" ;-)
Too many negatives in that sentence...I'm not sure. LOL
I address the security concerns in my whitepaper, which I'll share as soon as I can, but hundreds of people use VFPA. I believe if anything nefarious were happening (data pilfering, e.g.) it would have been discovered and the entire project would immediately collapse. Wireshark could easily sniff packets trying to be sent out to unauthorized places. Chen is staking his reputation on his integrity and so far there's no reason to question it.
Eric
On Tue, Nov 26, 2019 at 9:32 AM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
On 11/26/2019 7:20 AM, Peter Cushing wrote:
On 25/11/2019 17:36, Jürgen Wondzinski wrote:
Sometimes it would help to get off that Trump-level paranoia :)
wOOdy
"Just because you are paranoid doesn't mean Trump isn't out to get you"
;-)
Too many negatives in that sentence...I'm not sure. LOL
[excessive quoting removed by server]
On 11/21/2019 4:34 PM, Eric Selje wrote:
The Microsoft of 20 years ago probably would have complained, but they're a different company now. Their take is basically "If you want to modify the copy of VFP that you paid for, go for it."
Yeah, the ballmer days (thankfully) are long gone. That guy sucked.
Eric I copied and ran your code and sure enough it errors but with a nesting error Paul -----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Eric Selje Sent: 21 November 2019 17:59 To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
Sent by an external sender ------------------------------
This tweak adds rows so there's something to actually calculate. I tried it with many variations on fields and rows and cannot get it to crash.
#DEFINE _fields 35 #DEFINE _rows 100 =RAND(-1) CREATE CURSOR crsTest (id i) cCalcCmd = [CALCULATE ] cInsertFields = [] cInsertValues = [] FOR x = 1 TO _fields cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCalcCmd = cCalcCmd + "SUM("+cField+")," cInsertFields = cInsertFields + ","+cField cInsertValues = cInsertValues + ","+TRANS(INT(RAND()*100)) NEXT cInsertCmd = [INSERT INTO crsTest (ID ] + cInsertFields +[) VALUES (0]+cInsertValues+')' FOR X = 1 TO _rows &cInsertCmd NEXT cCalcCmd = cCalcCmd + "AVG(Field1)" &cCalcCmd
On Thu, Nov 21, 2019 at 11:37 AM Tracy Pearson tracy@powerchurch.com wrote:
Paul, There is no data in the cursor he created. How many records are you SUMming?
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Paul Newton Sent: Thursday, November 21, 2019 11:29 AM To: profoxtech@leafe.com Subject: RE: Fatal error issuing CALCULATE command
Hi Eric I think that's because the limit is 32 (not 31 as I stated). Try using For x = 1 To 33 and I think you will get the problem. Please let us know Thanks Paul Newton
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Eric Selje Sent: 21 November 2019 16:17 To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
Sent by an external sender
Interesting. I whipped up this test and cannot replicate the problem: CREATE CURSOR crsTest (id i) cCmd = [CALCULATE ] FOR x = 1 TO 32 cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCmd = cCmd + "SUM("+cField+")," NEXT cCmd = cCmd + "AVG(Field1)" &cCmd
On Thu, Nov 21, 2019 at 9:50 AM Paul Newton Paul.Newton@pegasus.co.uk wrote:
Hi all
I think I have come across a possibly undocumented limitation to the maximum number of expressions in a CALCULATE command. In my case a fatal error occurred when trying to CALCULATE the SUMs of 32 different fields in a cursor. It took a while to establish what was going on, but when I reduced the number of expressions to 31 the error no longer
occurred.
Has anybody else encountered this issue? Many thanks
Paul Newton
[excessive quoting removed by server]
Hi Tracy The problem doesn't lie in the number of records being SUMmed but in the number of fields being SUMmed being > 32 Paul
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Tracy Pearson Sent: 21 November 2019 17:37 To: profoxtech@leafe.com Subject: RE: Fatal error issuing CALCULATE command
Sent by an external sender ------------------------------
Paul, There is no data in the cursor he created. How many records are you SUMming?
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Paul Newton Sent: Thursday, November 21, 2019 11:29 AM To: profoxtech@leafe.com Subject: RE: Fatal error issuing CALCULATE command
Hi Eric I think that's because the limit is 32 (not 31 as I stated). Try using For x = 1 To 33 and I think you will get the problem. Please let us know Thanks Paul Newton
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Eric Selje Sent: 21 November 2019 16:17 To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
Sent by an external sender ------------------------------
Interesting. I whipped up this test and cannot replicate the problem: CREATE CURSOR crsTest (id i) cCmd = [CALCULATE ] FOR x = 1 TO 32 cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCmd = cCmd + "SUM("+cField+")," NEXT cCmd = cCmd + "AVG(Field1)" &cCmd
On Thu, Nov 21, 2019 at 9:50 AM Paul Newton Paul.Newton@pegasus.co.uk wrote:
Hi all
I think I have come across a possibly undocumented limitation to the maximum number of expressions in a CALCULATE command. In my case a fatal error occurred when trying to CALCULATE the SUMs of 32 different fields in a cursor. It took a while to establish what was going on, but when I reduced the number of expressions to 31 the error no longer
occurred.
Has anybody else encountered this issue? Many thanks
Paul Newton
[excessive quoting removed by server]
Paul
Do you mean you are doing this?
calculate sum(field1 + field2 + ... + field32) to lnTotal
No Alan - the following code (adapted from Eric) demonstrates exactly what I am doing:
#DEFINE _fields 35 #DEFINE _rows 100 =RAND(-1) CREATE CURSOR crsTest (id i) cCalcCmd = [CALCULATE ] cInsertFields = [] cInsertValues = [] cVariables = [] FOR x = 1 TO _fields cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCalcCmd = cCalcCmd + "SUM("+cField+")," cInsertFields = cInsertFields + ","+cField cInsertValues = cInsertValues + ","+TRANS(INT(RAND()*100)) cVariables = cVariables + "lc"+cField+"," NEXT cInsertCmd = [INSERT INTO crsTest (ID ] + cInsertFields +[) VALUES (0]+cInsertValues+')' FOR X = 1 TO _rows &cInsertCmd NEXT cCalcCmd = Left(cCalcCmd,Len(cCalcCmd)-1) + " To " + Left(cVariables,Len(cVariables)-1) &&+ "AVG(Field1)" ? cCalcCmd &cCalcCmd Return
Paul
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Alan Bourke Sent: 22 November 2019 12:55 To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
Sent by an external sender ------------------------------
Paul
Do you mean you are doing this?
calculate sum(field1 + field2 + ... + field32) to lnTotal
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
There definitely seems to be a limit of 32 as you say. Summing into an array as per below works for > 32 fields but I don't know if that would help.
#DEFINE _fields 35 #DEFINE _rows 100 Clear =RAND(-1) CREATE CURSOR crsTest (id i) cCalcCmd = [CALCULATE ] cCalcCmd2 = [ SUM ] cCalcCmd3 = "" cTemp = "" cInsertFields = [] cInsertValues = [] cVariables = [] FOR x = 1 TO _fields cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCalcCmd = cCalcCmd + "SUM("+cField+")," cCalcCmd2 = cCalcCmd2 + cField + "," cTemp = cTemp + cField + "," cInsertFields = cInsertFields + ","+cField cInsertValues = cInsertValues + ","+TRANS(INT(RAND()*100)) cVariables = cVariables + "lc"+cField+"," NEXT cInsertCmd = [INSERT INTO crsTest (ID ] + cInsertFields +[) VALUES (0]+cInsertValues+')' FOR X = 1 TO _rows &cInsertCmd Next lcVars = Left(cVariables,Len(cVariables)-1) cCalcCmd = Left(cCalcCmd,Len(cCalcCmd)-1) + " To " + Left(cVariables,Len(cVariables)-1) &&+ "AVG(Field1)" cCalcCmd2 = Left(cCalcCmd2,Len(cCalcCmd2)-1) + " To " + Left(cVariables,Len(cVariables)-1) cTemp = Left(cTemp,Len(cTemp)-1) *? cCalcCmd *? cCalcCmd2 ? cTemp ? lcVars =StrToFile(cCalcCmd + Chr(13) + Chr(13) + cCalcCmd2, "c:\temp\cmd.txt") ? Len(cCalcCmd2) *&cCalcCmd *&cCalcCmd2 Sum &cTemp to array laTots List Memory like laTots Return
Hi Alan
Yes it only seems to be when summing to variables. Changing it to an array would necessitate further changes elsewhere. I have changed the code to allow a maximum of 32 and if it exceeds 32 I construct another second command to deal with the rest of the fields/variables.
Paul
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Alan Bourke Sent: 22 November 2019 13:49 To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
Sent by an external sender ------------------------------
There definitely seems to be a limit of 32 as you say. Summing into an array as per below works for > 32 fields but I don't know if that would help.
#DEFINE _fields 35 #DEFINE _rows 100 Clear =RAND(-1) CREATE CURSOR crsTest (id i) cCalcCmd = [CALCULATE ] cCalcCmd2 = [ SUM ] cCalcCmd3 = "" cTemp = "" cInsertFields = [] cInsertValues = [] cVariables = [] FOR x = 1 TO _fields cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCalcCmd = cCalcCmd + "SUM("+cField+")," cCalcCmd2 = cCalcCmd2 + cField + "," cTemp = cTemp + cField + "," cInsertFields = cInsertFields + ","+cField cInsertValues = cInsertValues + ","+TRANS(INT(RAND()*100)) cVariables = cVariables + "lc"+cField+"," NEXT cInsertCmd = [INSERT INTO crsTest (ID ] + cInsertFields +[) VALUES (0]+cInsertValues+')' FOR X = 1 TO _rows &cInsertCmd Next lcVars = Left(cVariables,Len(cVariables)-1) cCalcCmd = Left(cCalcCmd,Len(cCalcCmd)-1) + " To " + Left(cVariables,Len(cVariables)-1) &&+ "AVG(Field1)" cCalcCmd2 = Left(cCalcCmd2,Len(cCalcCmd2)-1) + " To " + Left(cVariables,Len(cVariables)-1) cTemp = Left(cTemp,Len(cTemp)-1) *? cCalcCmd *? cCalcCmd2 ? cTemp ? lcVars =StrToFile(cCalcCmd + Chr(13) + Chr(13) + cCalcCmd2, "c:\temp\cmd.txt") ? Len(cCalcCmd2) *&cCalcCmd *&cCalcCmd2 Sum &cTemp to array laTots List Memory like laTots Return
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
On Fri, 22 Nov 2019, at 12:59 PM, Paul Newton wrote:
No Alan - the following code (adapted from Eric) demonstrates exactly what I am doing:
#DEFINE _fields 35 #DEFINE _rows 100 =RAND(-1) CREATE CURSOR crsTest (id i) cCalcCmd = [CALCULATE ] cInsertFields = [] cInsertValues = [] cVariables = [] FOR x = 1 TO _fields cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCalcCmd = cCalcCmd + "SUM("+cField+")," cInsertFields = cInsertFields + ","+cField cInsertValues = cInsertValues + ","+TRANS(INT(RAND()*100)) cVariables = cVariables + "lc"+cField+"," NEXT cInsertCmd = [INSERT INTO crsTest (ID ] + cInsertFields +[) VALUES (0]+cInsertValues+')' FOR X = 1 TO _rows &cInsertCmd NEXT cCalcCmd = Left(cCalcCmd,Len(cCalcCmd)-1) + " To " + Left(cVariables,Len(cVariables)-1) &&+ "AVG(Field1)" ? cCalcCmd &cCalcCmd Return
Paul
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Alan Bourke Sent: 22 November 2019 12:55 To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
Sent by an external sender
Paul
Do you mean you are doing this?
calculate sum(field1 + field2 + ... + field32) to lnTotal
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
Yes, Paul, that now makes my system crash with Fatal Error too in VFP9 and VFPA.
On Fri, Nov 22, 2019 at 6:59 AM Paul Newton Paul.Newton@pegasus.co.uk wrote:
No Alan - the following code (adapted from Eric) demonstrates exactly what I am doing:
#DEFINE _fields 35 #DEFINE _rows 100 =RAND(-1) CREATE CURSOR crsTest (id i) cCalcCmd = [CALCULATE ] cInsertFields = [] cInsertValues = [] cVariables = [] FOR x = 1 TO _fields cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCalcCmd = cCalcCmd + "SUM("+cField+")," cInsertFields = cInsertFields + ","+cField cInsertValues = cInsertValues + ","+TRANS(INT(RAND()*100)) cVariables = cVariables + "lc"+cField+"," NEXT cInsertCmd = [INSERT INTO crsTest (ID ] + cInsertFields +[) VALUES (0]+cInsertValues+')' FOR X = 1 TO _rows &cInsertCmd NEXT cCalcCmd = Left(cCalcCmd,Len(cCalcCmd)-1) + " To " + Left(cVariables,Len(cVariables)-1) &&+ "AVG(Field1)" ? cCalcCmd &cCalcCmd Return
Paul
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Alan Bourke Sent: 22 November 2019 12:55 To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
Sent by an external sender
Paul
Do you mean you are doing this?
calculate sum(field1 + field2 + ... + field32) to lnTotal
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
That's interesting, I wonder if this is documented in the Hacker's Guide.
I have to admit that in my 28 years of using VFP I've never used CALCULATE.
Frank.
Frank Cazabon
On 22/11/2019 12:24 PM, Eric Selje wrote:
Yes, Paul, that now makes my system crash with Fatal Error too in VFP9 and VFPA.
On Fri, Nov 22, 2019 at 6:59 AM Paul Newton Paul.Newton@pegasus.co.uk wrote:
No Alan - the following code (adapted from Eric) demonstrates exactly what I am doing:
#DEFINE _fields 35 #DEFINE _rows 100 =RAND(-1) CREATE CURSOR crsTest (id i) cCalcCmd = [CALCULATE ] cInsertFields = [] cInsertValues = [] cVariables = [] FOR x = 1 TO _fields cField = "Field"+TRANSFORM(x) ALTER table crsTest ADD COLUMN (cField) I cCalcCmd = cCalcCmd + "SUM("+cField+")," cInsertFields = cInsertFields + ","+cField cInsertValues = cInsertValues + ","+TRANS(INT(RAND()*100)) cVariables = cVariables + "lc"+cField+"," NEXT cInsertCmd = [INSERT INTO crsTest (ID ] + cInsertFields +[) VALUES (0]+cInsertValues+')' FOR X = 1 TO _rows &cInsertCmd NEXT cCalcCmd = Left(cCalcCmd,Len(cCalcCmd)-1) + " To " + Left(cVariables,Len(cVariables)-1) &&+ "AVG(Field1)" ? cCalcCmd &cCalcCmd Return
Paul
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Alan Bourke Sent: 22 November 2019 12:55 To: profoxtech@leafe.com Subject: Re: Fatal error issuing CALCULATE command
Sent by an external sender
Paul
Do you mean you are doing this?
calculate sum(field1 + field2 + ... + field32) to lnTotal
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
-
Alan Bourke -
Charlie Coleman -
Eric Selje -
Frank Cazabon -
Jean Laeremans -
Jürgen Wondzinski -
Koen Piller -
MB Software Solutions, LLC -
Paul H. Tarver -
Paul Newton -
Peter Cushing -
Tracy Pearson -
Vince Teachout