Alistair, you posted this:
...
> Nevertheless, mine is no monster database, but is ODBC a better way to
convert
> my data from Dos to Windows? As you can see from the above, Brent has
given me a
> solution to the import problem and JM has offered a solution to the
character
> conversion problem if I can't resolve it myself, but if the ASCII-ANSI
> conversion was done by ODBC it could save me a lot of time.
...
To my understanding, ODBC will not perform the ASCII-ANSI conversion.
You need to change the data. For example, e with an acute accent will be
found in your old data as CHAR(130). You need to change it to CHAR(233). You
need to do this for all the extended characters CHAR(128) through CHAR(255)
inclusive. Of course, you can leave out those characters which do not appear
in your data!
My conversion program isn't handy - it's been a few years - but I did it
like this: created a table ASCIIANSI with columns OldNum (ASCII character
code from 128 through 255) and NewNum (corresponding ANSI character code).
The program looped through a counter, vOldNum, that ran from 128 to 255. The
start of each loop would SELECT NewNum INTO vNewNum FROM ASCIIANSI WHERE
OldNum=.vOldNum. Then there was a series of commands like the following for
every possible column with an extended character in it:
UPDATE TableName SET ColumnName=(SRPL(ColumnName, CHAR(.vOldNum),
CHAR(.vNewNum),0)
A more elegant way of doing this would be to unload the old data as ASCII
and then load it into a word processor or text editor that can be configured
for either ANSI or ASCII. Import the text file as ASCII and then export it
as ANSI! My attempts to do this had mixed results (COREL WordPerfect worked
the best).
An extremely important second step once the conversion is done: PACK ALL
WITH USER CASE. This will impart the correct ANSI sequence and collation
tables to the database. Otherwise, you will get sorting and comparison
errors.
There is a problem with ANSI CHAR(255) which is a lower case "y" with an
umlaut. This character cannot be mapped to sort or equate to other "Y"s
because CHAR(255) is used internally by RBase as a placeholder for a null
value. I believe RBWin was shipping at one time with the line COLLATE 255 89
in the RBASE.CFG file. This causes some comparisons and sorts involving the
letter "z" to not work properly. Razzak confirmed this problem some time ago
on this list. This line should be removed from the CFG file, if it is
present. I doubt that your data has an umlaut y, but even if it does, the
chances are quite remote that collating the umlaut y after "z" will ever
affect you.
Hope that helps.
Regards,
Stephen Markson
ForenSys The Forensic Systems Group
www.ForensicSystemsGroup.com
416 482 2140
