Hi Bob, always nice to meet a fellow Cochran!
This is DB2/400 for V5R1 of OS/400, and yes it is stored in EBCDIC. I am
using the IBM supplied .Net Managed Provider to read the data into a C#
program, (which I believe automatically converts it to ASCII) and then using
the SQLite Managed Provider to insert the records into SQLite. The SQLite
version is the most recent (1.0.40?) and the platform is Windows. The data
file is then shipped to a Compact Framework application and is used on a
Windows Mobile device, so there is that platform as well.
Thanks,
--
Joel Cochran
On 3/26/07, Robert L Cochran <[EMAIL PROTECTED]> wrote:
What version if DB2 is this? Is your DB2 engine storing data in EBCDIC
format? What platform is the SQLite database on, and you didn't mention
the SQLite version.
If your DB2 data is EBCDIC did you convert it to ASCII before putting it
in SQLite? I want to point out the difference between an EBCDIC space
character ('X'40') and an ASCII space (X'20'). What translation table
you used if you did perform an EBCDIC to ASCII translation -- IBM offers
quite a few of them and sometimes you can get stuck with various
characters translating to X'C0' depending on the table used.
Of course, what I'm saying applies to Z/OS; it may be that AS/400 uses
ASCII by default. I'll try to check on that in the morning.
Thanks
Bob Cochran
Joel Cochran wrote:
> Howdy all,
>
> I am new to SQLite, so I hope this isn't too much of a newbie
> question, but
> I searched the Internet, the archives, and the help docs and could not
> find
> any mention of this.
>
> I am populating an SQLite database from a legacy IBM AS/400 database.
> The
> 400 stores all character fields with padded blanks. As a result, when I
> export the data the blanks remain. Normally this is not a problem, but
I
> noticed in SQLite when I do a select statement the MYFIELD = 'A' will
not
> work if the data is in fact 'A ' (a trailing blank).
>
> SQLite apparently does not ignore trailing blanks on character
> matching like
> other DBs do. Has anyone else experienced this, and if so what have you
> done about it? I know I could rewrite the export routine to trim the
> trailing blanks as they come out of the parent DB, but I was hoping
there
> may be another solution. If nothing else, maybe I can find one of you
to
> commiserate with!
>
> Thanks,
>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
