export gotcha

[Robert Haussmann]

John,

It doesn't appear to have anything to do with the underscore 
(I should have said that--in fact that was one of the first
things I looked at).

To verify, I just tried the following: 
	changing the "declare" to "decalre toemail(100,*)"
	changing the name of the export to "ail"

Both still have the same problem.

Note that I'm guessing in certain cases the issue might exist
but it doesn't have any effect on the processing.  For example,
if your export file is 20 fields long, and you have a variable
declared as whatever(5,.0), then it won't matter if clerk or
report sees the declare as a reference to the 5th field (because
elsewhere you are referencing a higher field).  It would
be interesting to see if that's the case in your example.

Bob

> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com 
> [mailto:filepro-list-bounces at lists.celestial.com] On Behalf 
> Of John Esak
> Sent: Sunday, November 14, 2004 5:54 PM
> To: filePro mailing list
> Subject: RE: export gotcha
> 
> Bob,
> I'm not sure what you have derived from this, or what you are 
> saying. I see
> your explanation of the bug quite clearly, but are you trying 
> to say it has
> something to do with the _ (under_bar_) type nameing or just 
> matching the
> last few letters of the variable and filename?  I don't 
> believe that is true
> because I often do have a varible called acctdet and do an 
> export of det. At
> least, I think I do. I'll check... but still the question 
> persists. Have you
> studied this any further? (ASsuming you wreen't too pissed 
> off over the
> first couple hours of investigation.:-) :-(  :-)
> 
> John
> 
> 
> > -----Original Message-----
> > From: filepro-list-bounces at lists.celestial.com
> > [mailto:filepro-list-bounces at lists.celestial.com]On Behalf Of Robert
> > Haussmann
> > Sent: Sunday, November 14, 2004 5:16 PM
> > To: filepro-list at seaslug.org
> > Cc: fpsupport at fptech.com
> > Subject: export gotcha
> >
> >
> > Here's a head's up to anyone using the export command to
> > create external files, in the hopes of saving someone
> > else a few hours of troubleshooting time.
> >
> > There's a potential conflict in naming arrays/variables and
> > exports that can cause unexpected results.  This is on
> > fileProODBC 1.0.13, though it probably exists on
> > other platforms as well.
> >
> > If you dimension an array with a name that ends in the
> > same as one of your exports, filePro can see the size
> > of the array as an export field, and set the maximum size
> > of export record incorrectly.
> >
> > For example:
> >
> > dim to_email(100)(30,*)
> > export ascii email=c:\temp.out r=\n f=\n
> > email(1)="test";write email
> >
> > While this should create a file with one record and
> > one field terminated by a newline, what you actually get
> > is one record with 100 fields, each terminated by a newline.
> > If the name of the export is changed to something other than
> > "email", you get the expected behavior.
> >
> > A quick test shows that it is not limited to array names,
> > but long variables as well (e.g., replace the first line
> > with "declare to_email(100,*)" and you get the same
> > result.
> >
> > Bob Haussmann
> > Tabor Children's Services, Inc.
> >
> >
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>