Table update Problem - "line too long" 
Author Message
 Table update Problem - "line too long"

    I have one particular TableUpdate command which won't consistently work.
This occurs with a buffered local view of a network FPW2.6 table which
contains a huge number of fields - 253 fields.  This table contains
every-20-minute data readings for a particular machine in our factory.  Each
record contains the readings for one particular batch.  The TableUpdate
works as long as the number of data readings for a batch doesn't get too
large.

    I'm guessing what's going on is that, when the user enters a large
number of data readings, the string being constructed to replace the data,
exceeds FoxPro's statement length limit.  In FPW 2.6, before views, I would
just have constructed two separate REPLACE statements, each referring to a
different portion of the table's fields, to solve a problem like this.  How
do you accomplish something like this when using views & TableUpdate?

    Thanks for any assistance.



Fri, 28 May 2004 23:23:24 GMT  
 Table update Problem - "line too long"
Randy,

You could break the views up into two or more each having the PK and some of
the fields.  The wrap your tableupdates() on the views in a transaction to
insure they either all get done or none of them get done.

JimB


Quote:
>     I have one particular TableUpdate command which won't consistently
work.
> This occurs with a buffered local view of a network FPW2.6 table which
> contains a huge number of fields - 253 fields.  This table contains
> every-20-minute data readings for a particular machine in our factory.
Each
> record contains the readings for one particular batch.  The TableUpdate
> works as long as the number of data readings for a batch doesn't get too
> large.

>     I'm guessing what's going on is that, when the user enters a large
> number of data readings, the string being constructed to replace the data,
> exceeds FoxPro's statement length limit.  In FPW 2.6, before views, I
would
> just have constructed two separate REPLACE statements, each referring to a
> different portion of the table's fields, to solve a problem like this.
How
> do you accomplish something like this when using views & TableUpdate?

>     Thanks for any assistance.



Fri, 28 May 2004 23:42:39 GMT  
 Table update Problem - "line too long"
Does this happen when you add a new record or edit an existing one?

There is a view property that governs how update commands are built.
? DBGetProp("viewname","VIEW","UpdateType" )

Using 0 - "Key fields only" may solve your problem.

Carl Karsten


Quote:
>     I have one particular TableUpdate command which won't consistently
work.
> This occurs with a buffered local view of a network FPW2.6 table which
> contains a huge number of fields - 253 fields.  This table contains
> every-20-minute data readings for a particular machine in our factory.
Each
> record contains the readings for one particular batch.  The TableUpdate
> works as long as the number of data readings for a batch doesn't get too
> large.

>     I'm guessing what's going on is that, when the user enters a large
> number of data readings, the string being constructed to replace the data,
> exceeds FoxPro's statement length limit.  In FPW 2.6, before views, I
would
> just have constructed two separate REPLACE statements, each referring to a
> different portion of the table's fields, to solve a problem like this.
How
> do you accomplish something like this when using views & TableUpdate?

>     Thanks for any assistance.



Sat, 29 May 2004 02:56:40 GMT  
 Table update Problem - "line too long"
The records for this table are set up initially with only a couple of values
assigned & all the other fields empty.
The error occurs only when editing this record.  In fact, I have now split
my view into two views, on the line of what Jim Booth suggested.  The error
still occurs.  Admittedly, this is somewhat over 100 fields apiece, but I
have other views which successfully update tables which contain over 100
fields.  I can try splitting into a third or fourth view.

This view property you suggest - "DBGetProp" - I'm not consciously setting
this anywhere, b/c all my views are designed in the Database Designer.  In
the "Update Criteria" tab, for the "SQL Where clause includes", I have "key
and modified fields" selected, but there is a "key fields only" option,
which may be the visual design equivalent of what you're suggesting.  Don't
I want to keep this selected as "key and modified fields", though?  The
problem is they mass key in this data after the fact, so they could easily
be keying in (worst case scenario) almost all 253 of these fields at once,
so "modified field" could include about every field in the table, and rarely
will include less than 100 of those fields.

Thanks again for any suggestions.


Quote:
> Does this happen when you add a new record or edit an existing one?

> There is a view property that governs how update commands are built.
> ? DBGetProp("viewname","VIEW","UpdateType" )

> Using 0 - "Key fields only" may solve your problem.

> Carl Karsten



> >     I have one particular TableUpdate command which won't consistently
> work.
> > This occurs with a buffered local view of a network FPW2.6 table which
> > contains a huge number of fields - 253 fields.  This table contains
> > every-20-minute data readings for a particular machine in our factory.
> Each
> > record contains the readings for one particular batch.  The TableUpdate
> > works as long as the number of data readings for a batch doesn't get too
> > large.

> >     I'm guessing what's going on is that, when the user enters a large
> > number of data readings, the string being constructed to replace the
data,
> > exceeds FoxPro's statement length limit.  In FPW 2.6, before views, I
> would
> > just have constructed two separate REPLACE statements, each referring to
a
> > different portion of the table's fields, to solve a problem like this.
> How
> > do you accomplish something like this when using views & TableUpdate?

> >     Thanks for any assistance.



Sat, 29 May 2004 05:46:59 GMT  
 Table update Problem - "line too long"

Randy,

Quote:
> The records for this table are set up initially with only a couple of
values
> assigned & all the other fields empty.
> The error occurs only when editing this record.  In fact, I have now split
> my view into two views, on the line of what Jim Booth suggested.  The
error
> still occurs.  Admittedly, this is somewhat over 100 fields apiece, but I
> have other views which successfully update tables which contain over 100
> fields.  I can try splitting into a third or fourth view.

That should work too, but I would hold off.  The following may help you get
it all done in one view.

Quote:

> This view property you suggest - "DBGetProp" - I'm not consciously setting
> this anywhere, b/c all my views are designed in the Database Designer.  In
> the "Update Criteria" tab, for the "SQL Where clause includes", I have
"key
> and modified fields" selected, but there is a "key fields only" option,
> which may be the visual design equivalent of what you're suggesting.

Correct.  Try setting that to "Key Fields Only."

Quote:
> Don't
> I want to keep this selected as "key and modified fields", though?

See the wiki pages below for why.

Quote:
>The
> problem is they mass key in this data after the fact, so they could easily
> be keying in (worst case scenario) almost all 253 of these fields at once,
> so "modified field" could include about every field in the table, and
rarely
> will include less than 100 of those fields.

You may want to trim the UpdateName.  I don't see a way to do this in the
visual designer, but it is good to learn how to work with other view tools
(prg or 3rd party GUIs.)

The default is "Table.Field".  Dropping "Table." may shorten the length of
the update command that VFP is trying to run.

? DBGetProp( "MyView1.cFid1", "field", "UpdateName" )
Tbl.cFid1
? DBSetProp( "MyView1.cFid1", "field", "UpdateName", "cFid1" )
.t.
? DBGetProp( "MyView1.cFid1", "field", "UpdateName" )
cFid1

However, dropping the table may cause another problem.  From the ViewEditor
page:

"The View Designer will sometimes drop the database-and-exclamation-point
qualification for the UpdateName property of view fields, causing fields
marked as updatable to not properly update."

If someone can elaborate on this and it's effect on your situation, that
would be grand.

http://fox.wikis.com/wc.dll?Wiki~VfpViews~VFP

http://fox.wikis.com/wc.dll?Wiki~ViewEditor~VFP

Carl Karsten



Sat, 29 May 2004 08:06:18 GMT  
 Table update Problem - "line too long"
Randy
This probelm has been cared for with
SYS(3055) FOR and WHERE Clause Complexity
-Anders


Quote:
>     I have one particular TableUpdate command which won't consistently
work.
> This occurs with a buffered local view of a network FPW2.6 table which
> contains a huge number of fields - 253 fields.  This table contains
> every-20-minute data readings for a particular machine in our factory.
Each
> record contains the readings for one particular batch.  The TableUpdate
> works as long as the number of data readings for a batch doesn't get too
> large.

>     I'm guessing what's going on is that, when the user enters a large
> number of data readings, the string being constructed to replace the data,
> exceeds FoxPro's statement length limit.  In FPW 2.6, before views, I
would
> just have constructed two separate REPLACE statements, each referring to a
> different portion of the table's fields, to solve a problem like this.
How
> do you accomplish something like this when using views & TableUpdate?

>     Thanks for any assistance.



Sat, 29 May 2004 10:23:44 GMT  
 Table update Problem - "line too long"
Thanks much, Anders!  This solved my problem.

I placed SYS(3055, 8*253) before the TableUpdate command, & then SYS(3055)
in my "ExitForm" method.
Testing the same data entry process, before & after, the save failed before
adding these statements, but worked successfully after adding them.
Checking the data file afterwards, the data truly had been saved as desired.

I am using two views, each containing about half of the table's fields,
instead of the original single view. This suggestion, made by others in this
thread, I will probably retain since it's working as is, unless you would
recommend recombining them into a single view & making the necessary form
changes.

Thanks again!


Quote:
> Randy
> This probelm has been cared for with
> SYS(3055) FOR and WHERE Clause Complexity
> -Anders



> >     I have one particular TableUpdate command which won't consistently
> work.
> > This occurs with a buffered local view of a network FPW2.6 table which
> > contains a huge number of fields - 253 fields.  This table contains
> > every-20-minute data readings for a particular machine in our factory.
> Each
> > record contains the readings for one particular batch.  The TableUpdate
> > works as long as the number of data readings for a batch doesn't get too
> > large.

> >     I'm guessing what's going on is that, when the user enters a large
> > number of data readings, the string being constructed to replace the
data,
> > exceeds FoxPro's statement length limit.  In FPW 2.6, before views, I
> would
> > just have constructed two separate REPLACE statements, each referring to
a
> > different portion of the table's fields, to solve a problem like this.
> How
> > do you accomplish something like this when using views & TableUpdate?

> >     Thanks for any assistance.



Sat, 29 May 2004 23:43:31 GMT  
 Table update Problem - "line too long"
Shouldn't that be SYS(3055, 8 * 40) in your ExitForm method (assuming that
you want to reset it to the default value) ?

 - Rush


Quote:
> Thanks much, Anders!  This solved my problem.

> I placed SYS(3055, 8*253) before the TableUpdate command, & then SYS(3055)
> in my "ExitForm" method.
> Testing the same data entry process, before & after, the save failed
before
> adding these statements, but worked successfully after adding them.
> Checking the data file afterwards, the data truly had been saved as
desired.

> I am using two views, each containing about half of the table's fields,
> instead of the original single view. This suggestion, made by others in
this
> thread, I will probably retain since it's working as is, unless you would
> recommend recombining them into a single view & making the necessary form
> changes.

> Thanks again!



Sun, 30 May 2004 06:35:01 GMT  
 Table update Problem - "line too long"

Quote:
> I am using two views, each containing about half of the table's fields,
> instead of the original single view. This suggestion, made by others in
this
> thread, I will probably retain since it's working as is, unless you would
> recommend recombining them into a single view & making the necessary form
> changes.

I would combine them back.  If anyone ever has to do anything with this, it
will throw them for a loop.  Fix it now while this is all fresh in you head.

Glad you got it worked out.  I totally forgot about that sys() thingy.

Carl Karsten



Sun, 30 May 2004 07:11:32 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Q: "LINE TOO LONG"

2. "Line too long to fit" Error

3. "line is too long"

4. "Cannot update cursor" on a table

5. Problem with CURSORSETPROP("Tables")

6. String too long in PICTURE "@M"

7. Update: "Abnormal Program termination" - FYI

8. Help with "Cannot Update File" error

9. "Update Conflict" error

10. "Cannot Update the cursor" Error

11. complaining about VFP3.0 "update"(SQL)

12. Updating DBF : "invalid parameter number",

 

 
Powered by phpBB® Forum Software