[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 784
  • Last Modified:

Mainframe Data Conversion

Hello,

Here's what seems like a strange one (to me anyway).  I have a file I exported from an IBM z/OS mainframe using IND$FILE to transfer it out.  The file is created with a COBOL program that converts packed data and gets it into a format we can use in PC land.  Not exactly sure of all the details but, that's it in a nutshell.  

The resulting text file looks like it should.  Pipe delimited text with no strange characters.  Just letters and numbers and the occasional special character here and there.  I have imported the file into Excel as text.  Again, everything looks good.

The problem comes when I import into SQL using SSMS Import Data Wizard.   The data is imported into my table and I can run queries against it in SSMS and everything looks great but, I run into trouble using the data in our ASP.NET application.  Some reports work, others don't.  It seems like it could be an issue with numbers which get converted to dates.

I have tested the application with other data which we exported preciously and everything looks and works correctly.  As soon as I load our main table up with the new data, we run into trouble.  

Does this sound familiar to anyone?  Could it be something like a unicode or ascii issue or something?  I'm lost.  Any help would be greatly appreciated.  

TIA  
0
ttist25
Asked:
ttist25
1 Solution
 
lcohanDatabase AnalystCommented:
It could be a ASCII/UNICODE issue, Localle settings, Code page, or SQL collation for that matter.
You need to match the data type from the source with the target table and keep in mind that some odd chars even though they display exactly the same on your screen they may have different hex code under differnet code pages and this can cause big headaches.
0
 
ttist25Author Commented:
Thanks for the answer.  It is appreciated.  

Unfortunately (or fortunately depending on how you look at it) the issue was not with the encoding of the data but the actual values themselves.  The users at this site entered values other than the standard values for some of the fields.

That messed up the stored procedures in SQL because they were looking for values that weren't in the data.  

The lesson here?  Stop and look!  I jumped to conclusions and wasted HOURS.  

Live and learn right?  

Thanks again.
0

Featured Post

Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now