Flat Files recognizing Numeric vs Char fields

I am creating an ASCII file, which will be transmitted to an external source via FTP.  In the file, if field lengths are shorter then what the file layout requires, then I need to pad either with trailing spaces or leading zeros depending on the data type.

My question is this, when I have a numeric field, the leading zeros are removed, and in many cases I need them to exist.  So, if I use a string field and force a right justify by padding leading zeros, will there be anyway to tell when the data is extracted by the external source that it was not a numeric field?  
Able22Asked:
Who is Participating?
 
SRigneyCommented:
The external application gets everything as a string.
By you meeting their format they probably already have an application set up to parse the field correctly and put it into their database.

They don't know or care if you store your data as a string or a number, as long as it's in the file in the format that they want.
0
 
aflat362Commented:
No
0
 
Able22Author Commented:
So this method will work?
0
Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

 
leonstrykerCommented:
It really depends on that is used to extract the data.  Some applications make the assessment as they import, others can use a format file, while still others make a guess based on the data in the field.  Do you know what the files are going to be used for and how?

Leon
0
 
Richie_SimonettiIT OperationsCommented:
"My question is this, when I have a numeric field, the leading zeros are removed, and in many cases I need them to exist..."
But if you need them to exist, it is not a numeric field....
0
 
Able22Author Commented:
I understand your point Richie_Simonetti, however, here is an example:  The ASCII file layout that is required by the external vendor has a NUMERIC field, Cust_ID.  CUST_ID has a required length of 10.   However, my company's Cust_ID field is only a length of 6.  It is specified in the specs that if my field lengths don't match the ones in the given file layout, then I have to pad accordingly.  Therefore, I'd have to add 4 extra zeros to the beginning of my CUST_ID value to make it equal a length of 110.   So, I was wondering if I changed the CUST_ID to a string and added the zeros and printed it to the file, when the extract the data, will I cause a data-type mismatch.............
0
 
Able22Author Commented:
oops,  in the above comment, 10, not 110....
0
 
leonstrykerCommented:
The answer is: "Not likely, but posible".  Most software pakages or application will convert it to numeric using some form of "type casting".

Leon
0
 
Richie_SimonettiIT OperationsCommented:
Could you replace those leading 0 by spaces?
I am asking you this 'cause i do a regular job on this kind of things (convert excel files to fixed length ascci files for SAP).
0
 
Dang123Commented:
Try writing your numbers using the format command

     Format(intCustID, "0000000000")


This will allow you to output your numbers with zero padding easily. The data will be pulled into the reading program as it expects it. I also work with COBOL, and there a field that contains any non-numeric characters (except for one period) is considered a character string. this method would definitely work to pass a number. The only way to be sure though is to send a test file to the program that needs to read your file.
0
 
aflat362Commented:
In a test enviornment - print it numerically, print it as a string.  Compare the 2 output files.  If you can tell no difference - the application which reads it can't either.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.