Marc,
I don't have any idea (yet) how your first problem might occur but I have a
suggestion for the second one:
Are you using double or single quotes? If single, do you have any data with,
mistakenly, two single quotes in a name?
O''Dell instead of O'Dell
If so, that will cause you errors
If you're using double quotes do you have any in the data instead of single
ones? Again, this could cause errors.
Regards,
Alastair.
From: MDRD
Sent: Wednesday, April 28, 2010 1:11 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - RE: Another Strange problem
Tony
My biggest problem is all of my users are out of state and some users have
not updated my APP in years
or may have missed some updates.
I was wondering if the " and , in some of my fields was throwing things off.
I will give this a test later today.
Thanks
Marc
From: A.G. IJntema
Sent: Wednesday, April 28, 2010 1:00 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - RE: Another Strange problem
Maybe you can do it in another way. This is the way how I have done it
succesfully several times
First I define per table a variable with all the columns in it , which you
like to convert
-- CAO
SET VAR V_CAO_COL =
'CAO_ID,JRTL_ID,CAO_volgnr,CAO_mnd,CAO_pro,CAO_vb,CAO_min,CAO_max'
Open old database
Then unload the data as ascii
-- CAO
OUTPUT CAO.PDN
UNLOAD DATA FOR CAO USING &V_CAO_COL AS ASCII
OUTPUT SCREEN
Open new database
To be sure the new table is empty I run the statement:
DELETE ROWS FROM CAO
Finally the data are loaded into the new table as ascii
SET SEMI=NULL
SET SEMI='^'
LOAD CAO FROM CAO.PDN USING &V_CAO_COL ^ NOCHECK ^ NONUM
SET SEMI=NULL
SET SEMI=';'
In this way you are in control of the conversion and you can add some checks
and balances in the routine.
For instance count the number of rows in the old and new table, you easily
can avoid calculated fields and so on .
With defining the columns as a variable you are sure the structure is the
same in the old and new version.
Another advantage is you can optimize the new database in the way you like to
have it and in the end there is a clean situation, which is the same for
everyone.
The only thing you have to keep in mind is the order of loading the data into
the new database. PK's and FK's
Hope this helps.
Tony IJntema
From: rbas...@rbase
.com [mailto:[email protected]] On Behalf Of MDRD
Sent: woensdag 28 april 2010 0:00
To: RBASE-L Mailing List
Subject: [RBASE-L] - Another Strange problem
Hi
I am trying to update my users to 7,6 and I thought I would
Unload Data for Table Using ..... for all the data tables then load them into
a blank 7.6 DB.
Some of my users haven't updated my app for years and and I thought this
would be a good way to make sure they had the exact
same structure I had. I have dozens of out of state users.
I did not get any errors but to double check the data I did a Unload All on
the original DB and the new 7.6 DB
after I loaded the data. Then I compared the 2 files to see if the data
matched and it did Not?
In the first example you can see the 2 was changed to a 3... very strange.
In the second example, don't worry I changed the name and numbers with fake
data
But you can see on the second line a -0- was replaced with a SS number from
the first line
You can see that they have "dell" for the name so I wonder if that is the
problem. Also I noticed sometimes they have\
Smith, Jr in the last name on some customers but sometimes there is no
strange " or , in the data and the data after the
load is different.
This makes me real nervous about sending out my update.
neb',-0-,'244999999','3','N','N','N','IN',0,'Same','1','318 Valley Stream+
--- original file
neb',-0-,'344999999','3','N','N','N','IN',0,'Same','1','318 Valley Stream+
-- after Load
9444',-0-,11/12/1967,'Y','243089000','F','5','M','L','1','Sam O''dell',+ ---
original file
-0-,-0-,'3','N','Y','N','IN',0,'Eddie, Kryan','2','3400 Fixcraft Road','Char+
9444',-0-,11/12/1967,'Y','243089000','F','5','M','L','1','Sam O''dell',+
--- after Load
-0-,'243089000','3','N','Y','N','IN',0,'Eddie, Kryan','2','3400 Fixcraft Roa+
Any suggestions?
Marc
------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.814 / Virus Database: 271.1.1/2839 - Release Date: 04/27/10
19:27:00
