Discussion:
COPY TO is changing char values to numeric
(too old to reply)
Charles Crume
2004-02-06 04:03:53 UTC
Permalink
Hello all;

I've run into a weird, weird problem. I want to copy a table and then use
the copy for some operations. I ran the following commands:

----------------------------
clear
select 1; use data\ma
list ma_booth, ma_clerk, ma_gross, ma_net
copy to temp\ax
select 9; use temp\ax
list ma_booth, ma_clerk, ma_gross, ma_net
----------------------------

and the results, from the two list commands, in the command pane is shown
below:

----------------------------
Record# ma_booth ma_clerk ma_gross ma_net
1 RFFwd gK 202.42 142551888.00
2 oISlm A 0.57
80614024.00
3 z T 518708000.00
3633.64
4 jR UAc 844897.19
18.32
5 ZCa RU 239222640.00 2876035584.00
6 rbSI VDS 0.91
0.15
7 DRLfQC XbO 29.75 2.09


Record# ma_booth ma_clerk ma_gross ma_net
1 RFFwd 2.5 202.42 142551888.00
2 oISlm 0.8 0.57
80614024.00
3 z 0.7 518708000.00
3633.64
4 jR 14.3 844897.19
18.32
5 ZCa 1.6 239222640.00 2876035584.00
6 rbSI 80.7 0.91
0.15
7 DRLfQC 0.6 29.75
2.09
----------------------------

As one can see, the MA_CLERK field has had it's values changed from char to
numeric (I checked each table's structure via the MODI STRUCTURE command and
MA_CLERK is a char 5 field in *both* tables.

I am baffled. Have shut down vDB (v5.7) and Windows (Win98se) 3 time to see
if something was goofy.

Does anyone have any ideas??

TIA.

Charles...


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/04
Romain Strieff [dBVIPS]
2004-02-06 05:10:50 UTC
Permalink
In article Charles Crume, ***@charlescrumesoftware.com politely
paraphrased...
Post by Charles Crume
I am baffled. Have shut down vDB (v5.7) and Windows (Win98se) 3 time to see
if something was goofy.
Does anyone have any ideas??
any turnkey that reproduces it?
--
Romain Strieff [dBVIPS]
http://www.dbase.com/Docs/newsguid.htm
Charles Crume
2004-02-06 06:42:01 UTC
Permalink
Yes -- I've posted a msg and small attachment to the binaries newsgroup.
Post by Romain Strieff [dBVIPS]
paraphrased...
Post by Charles Crume
I am baffled. Have shut down vDB (v5.7) and Windows (Win98se) 3 time to see
if something was goofy.
Does anyone have any ideas??
any turnkey that reproduces it?
--
Romain Strieff [dBVIPS]
http://www.dbase.com/Docs/newsguid.htm
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/04
Carlos Pereira
2004-02-06 09:35:28 UTC
Permalink
Charles Crume

To remind always: who and what is active?

See code sample:

******
CLEAR
*
SELECT 1
USE data\ma ALIAS ma
SET FIELDS TO ma->ma_clerk,ma-> ma_gross,ma->ma_net
COPY TO temp\ax ALL
SET FIELDS TO
*
SELECT 9
USE data\ax ALTAS ax
SET FIELDS TO ax->ma_clerk,ax-> ma_gross,ax->ma_net
LIST && or BROWSE or ...
...
SET FIELDS TO
...
******

Carlos Pereira
APKomp, LDA.
Charter Member: 100 0259
(Gold Subscription)



----- Original Message -----
From: "Charles Crume" <***@charlescrumesoftware.com>
Newsgroups: dbase.version5
Sent: Friday, February 06, 2004 4:03 AM
Subject: COPY TO is changing char values to numeric
Post by Charles Crume
Hello all;
I've run into a weird, weird problem. I want to copy a table and then use
the copy for some operations.
Fred van der Meulen
2004-02-06 13:21:43 UTC
Permalink
Hello Charles,
Post by Charles Crume
Hello all;
I've run into a weird, weird problem. I want to copy a table and then use
----------------------------
clear
select 1; use data\ma
list ma_booth, ma_clerk, ma_gross, ma_net
copy to temp\ax
select 9; use temp\ax
list ma_booth, ma_clerk, ma_gross, ma_net
----------------------------
Tried your example and it gave the result you've described, in dBase+
But IŽve noticed that the _DBASELOCK field is causing the problem.

When you copy the ma table to the ax table, the _DBASELOCK field is not
copied. When you move the _DBASELOCK field to position 43 (in the table
disigner), you will see the same result on both tables.

Regards,
Fred.
Charles Crume
2004-02-07 18:54:35 UTC
Permalink
Hi Fred;

Vewy interwesting. You know, I looked at the structure of the copied table
but DID NOT notice that the _DBASELOCK field was missing!!

Back in Sep '01 I posted the msg "Adding a field via ALTER TABLE to a table
with _DBASELOCK" to see if I would run into problems.

OK -- now don't start flaming me over this (I'm not wanting to stir up
trouble, or point fingers at anyone -- I always appreciate all the help),
but we should let everyone know that it looks like altering a table and NOT
moving the lock field to the last position will cause a problem in this case
(or maybe not, I could be missing something).

It looks like using the SET FIELDS command will be a good usable workaround
(in this case), so I can proceed with the task I am working on.

However, the question is "should this be reported as a bug??" or is there a
way to alter a table and move the _DBASELOCK field to the last position

Charles...
Post by Fred van der Meulen
Hello Charles,
Tried your example and it gave the result you've described, in dBase+
But IŽve noticed that the _DBASELOCK field is causing the problem.
When you copy the ma table to the ax table, the _DBASELOCK field is not
copied. When you move the _DBASELOCK field to position 43 (in the table
disigner), you will see the same result on both tables.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.580 / Virus Database: 367 - Release Date: 2/6/04
Ken Mayer [dBASE, Inc.]
2004-02-07 19:12:46 UTC
Permalink
Post by Charles Crume
It looks like using the SET FIELDS command will be a good usable workaround
(in this case), so I can proceed with the task I am working on.
However, the question is "should this be reported as a bug??" or is there a
way to alter a table and move the _DBASELOCK field to the last position
Well, first off, posting bug reports for Visual dBASE 5.x is kinda
useless. <g>

Second off ... since you know what the problem is, use alter table to
delete the _dbaselock field, and add the new field, then re-convert
the table (to add the _dbaselock field at the end again). That's
really all you can do.

Ken
---
Ken Mayer [dBASE, Inc.]
** Please respond ONLY in the newsgroups **

"Think OOP"

dBASE, Inc. website: http://www.dbase.com
Charles Crume
2004-02-08 02:03:01 UTC
Permalink
Post by Ken Mayer [dBASE, Inc.]
Well, first off, posting bug reports for Visual dBASE 5.x is kinda
useless. <g>
Did you see Romain's response to my post in binaries? Same problem in
Plus...
Post by Ken Mayer [dBASE, Inc.]
Second off ... since you know what the problem is, use alter table to
delete the _dbaselock field, and add the new field, then re-convert
the table (to add the _dbaselock field at the end again). That's
really all you can do.
That's what I plan on doing and that will be OK now that I know about the
issue.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.580 / Virus Database: 367 - Release Date: 2/6/04
Ken Mayer [dBASE, Inc.]
2004-02-08 02:24:12 UTC
Permalink
Post by Charles Crume
Post by Ken Mayer [dBASE, Inc.]
Well, first off, posting bug reports for Visual dBASE 5.x is kinda
useless. <g>
Did you see Romain's response to my post in binaries? Same problem in
Plus...
No. I don't read messages in binaries unless I am planning on
downloading the attachment. <g>
Post by Charles Crume
Post by Ken Mayer [dBASE, Inc.]
Post by Ken Mayer [dBASE, Inc.]
Second off ... since you know what the problem is, use alter table to
delete the _dbaselock field, and add the new field, then re-convert
the table (to add the _dbaselock field at the end again). That's
really all you can do.
That's what I plan on doing and that will be OK now that I know about the
issue.
The big thing here is that this is not really a bug. It's a
frustration, but ... (I mean, you can go into the table designer and
add a field after the _dbaselock field, too ... and you'll have the
same problems ...)

Ken
---
Ken Mayer [dBASE, Inc.]
** Please respond ONLY in the newsgroups **

"Think OOP"

dBASE, Inc. website: http://www.dbase.com
Charles Crume
2004-02-08 05:40:07 UTC
Permalink
Post by Ken Mayer [dBASE, Inc.]
The big thing here is that this is not really a bug. It's a
frustration, but ... (I mean, you can go into the table designer and
add a field after the _dbaselock field, too ... and you'll have the
same problems ...)
A frustration? Of course. But also perhaps a bug, as one would tend to think
that COPY TO would copy *all* the fields in a table (including _DBASELOCK).
I, for one, believe that *all* the fields should be copied (don't understand
why it wouldn't be -- is there some technical reason??)

Way back in '01, I had a nagging thought in the back of my mind that
_DBASELOCK was supposed to be the *last* field in a table. Could not find
any info regarding it, so I posted a msg. Was told not to worry about it
(which is OK), but have now discovered a problem, which, apparently, is not
readily known as Romain tested my turnkey in Plus (again OK, I appreciate
your taking a look at it Romain).

Anyway, I guess dBASE, Inc will have to decide whether it's a bug or not and
whether to change the COPY TO command.

At least, might I suggest a special note be added to the documentation of
the COPY TO command about this?

Charles...


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.580 / Virus Database: 367 - Release Date: 2/6/04
Ken Mayer [dBASE, Inc.]
2004-02-08 06:05:34 UTC
Permalink
Post by Charles Crume
Post by Ken Mayer [dBASE, Inc.]
frustration, but ... (I mean, you can go into the table designer and
add a field after the _dbaselock field, too ... and you'll have the
same problems ...)
A frustration? Of course. But also perhaps a bug, as one would tend to think
that COPY TO would copy *all* the fields in a table (including _DBASELOCK).
I, for one, believe that *all* the fields should be copied (don't understand
why it wouldn't be -- is there some technical reason??)
That I can't say. However, a bug report for this was filed some time
ago (QAID: 587). I hadn't read that thread (as noted), so hadn't seen
any of that.

Ken
---
Ken Mayer [dBASE, Inc.]
** Please respond ONLY in the newsgroups **

"Think OOP"

dBASE, Inc. website: http://www.dbase.com
Glenn Fausel
2004-02-08 06:52:21 UTC
Permalink
Post by Charles Crume
Post by Ken Mayer [dBASE, Inc.]
The big thing here is that this is not really a bug. It's a
frustration, but ... (I mean, you can go into the table designer and
add a field after the _dbaselock field, too ... and you'll have the
same problems ...)
A frustration? Of course. But also perhaps a bug, as one would tend to think
that COPY TO would copy *all* the fields in a table (including _DBASELOCK).
I, for one, believe that *all* the fields should be copied (don't understand
why it wouldn't be -- is there some technical reason??)
In case no one checked, if you just copy structure, same error results.
Thought that might be a way around it.

Glenn Fausel
Romain Strieff [dBVIPS]
2004-02-08 09:53:40 UTC
Permalink
In article Charles Crume, ***@charlescrumesoftware.com politely
paraphrased...
Post by Charles Crume
A frustration? Of course. But also perhaps a bug, as one would tend to think
that COPY TO would copy *all* the fields in a table (including _DBASELOCK).
I, for one, believe that *all* the fields should be copied (don't understand
why it wouldn't be -- is there some technical reason??)
It says so in the OLH.

Description

Use COPY to copy all or part of a table to a file of the same or a
different type. If an index is active, COPY arranges the records of the
new table or file according to the indexed order.
The COPY command does not copy a _DBASELOCK field in a table that you've
created with CONVERT.
The COPY command does not copy standard, custom or referential integrity
properties to the new file. Standard properties include default,
maximum, minimum and required.
COPY TO [WITH] PRODUCTION results in a table whose natural order mimics
that of the active index being copied.
...
--
Romain Strieff [dBVIPS]
http://www.dbase.com/Docs/newsguid.htm
Charles Crume
2004-02-08 18:53:38 UTC
Permalink
Boy, I missed that!!!!
Post by Romain Strieff [dBVIPS]
It says so in the OLH.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.580 / Virus Database: 367 - Release Date: 2/6/04
Romain Strieff [dBVIPS]
2004-02-09 10:40:47 UTC
Permalink
In article Charles Crume, ***@charlescrumesoftware.com politely
paraphrased...
Post by Charles Crume
Post by Romain Strieff [dBVIPS]
It says so in the OLH.
Boy, I missed that!!!!
tsts.;-)
--
Romain Strieff [dBVIPS]
http://www.dbase.com/Docs/newsguid.htm
Loading...