Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

NUMERIC data type in FoxPro

7 posts in FoxPro Last posting was on 2011-07-24 06:06:21.0Z
Yury Vitovsky Posted on 2011-07-20 13:16:03.0Z
Content-Type: multipart/mixed; boundary=----------wqyCOQsUDDD6Kfyqw4F0rD
Newsgroups: Advantage.FoxPro
Subject: NUMERIC data type in FoxPro
Date: Wed, 20 Jul 2011 16:16:03 +0300
MIME-Version: 1.0
From: "Yury Vitovsky" <yura@wgsoftpro.com>
Organization: SoftPro
Message-ID: <op.vyw5s11nhx6u6k@yura-note>
User-Agent: Opera Mail/11.50 (Win32)
X-Original-NNTP-Posting-Host: yura.masq.lc
X-Original-Trace: 20 Jul 2011 16:16:01 +0300, yura.masq.lc
Lines: 123
NNTP-Posting-Host: 89.162.137.146
X-Trace: 20 Jul 2011 06:16:26 -0700, 89.162.137.146
Path: solutions.advantagedatabase.com!192.168.0.1!not-for-mail
Xref: solutions.advantagedatabase.com Advantage.FoxPro:371
Article PK: 1109727

Hello,
our customer has Visual FoxPro application and data in DBF format.
Now he tries to migrate this database to Advantage and gets the problem
with NUMERIC fields.
- Visual FoxPro NUMERIC field have format 6,2. It's Ok for FoxPro
application to input value up to 9999.99 into this field.
- ARC32 show this format and value the same, but user can't insert value
greater than 999.99 in this field.

Please find in attachment small sample table that was created in Visual
Foxpro. See last field IZNOS_K and its value (1030.4, it was entered in
Visual FoxPro database).
Please open it as Visual FoxPro dbf table by arc32 and try to edit this
value simple by pressing F2 and Enter. You will get an error.
So Visual FoxPro exclude decimal point from dbf format length, but
Advantage DBF does not.
And what is the correct way to migrate this data to Advantage? We just
advised them to increase field length, but they have some hundreds of such
fields and it is a bit laborious…

Regards,
Yury Vitovsky
SoftPro
Ukraine


Alex Wong Posted on 2011-07-20 17:45:29.0Z
Date: Wed, 20 Jul 2011 17:45:29 +0000 (UTC)
Message-ID: <9d1879957b9a8ce14e9a858b171@devzone.advantagedatabase.com>
From: Alex Wong <someone@sybase.com>
Subject: Re: NUMERIC data type in FoxPro
Newsgroups: Advantage.FoxPro
References: <op.vyw5s11nhx6u6k@yura-note>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=utf-8; format=flowed
X-Newsreader: JetBrains Omea Reader 1098.1
NNTP-Posting-Host: 10.6.193.123
X-Trace: 20 Jul 2011 10:45:26 -0700, 10.6.193.123
Lines: 46
Path: solutions.advantagedatabase.com
Xref: solutions.advantagedatabase.com Advantage.FoxPro:372
Article PK: 1109724

Hi Yury,

Increasing the field length is probably the best solution.

It is not the decimal point that is excluded, it is the sign that is exclude.
In fact, it is actually allowed to store 999999 in numeric 6, 2 in FoxPro.
The xBase standard does not enforce the decimal. As long as the data fits
in the given field width, 7 characters in this case, it is allowed. This
is just a quirk of the DBF and best to avoid using such behavior.

--
Alex

> Hello,
> our customer has Visual FoxPro application and data in DBF format.
> Now he tries to migrate this database to Advantage and gets the
> problem
> with NUMERIC fields.
> - Visual FoxPro NUMERIC field have format 6,2. It's Ok for FoxPro
> application to input value up to 9999.99 into this field.
> - ARC32 show this format and value the same, but user can't insert
> value
> greater than 999.99 in this field.
> Please find in attachment small sample table that was created in
> Visual
> Foxpro. See last field IZNOS_K and its value (1030.4, it was entered
> in
> Visual FoxPro database).
> Please open it as Visual FoxPro dbf table by arc32 and try to edit
> this
> value simple by pressing F2 and Enter. You will get an error.
> So Visual FoxPro exclude decimal point from dbf format length, but
> Advantage DBF does not.
> And what is the correct way to migrate this data to Advantage? We just
> advised them to increase field length, but they have some hundreds of
> such
> fields and it is a bit laborious…
> Regards,
> Yury Vitovsky
> SoftPro
> Ukraine


Yury Vitovsky Posted on 2011-07-21 09:38:37.0Z
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Newsgroups: Advantage.FoxPro
Subject: Re: NUMERIC data type in FoxPro
References: <op.vyw5s11nhx6u6k@yura-note> <9d1879957b9a8ce14e9a858b171@devzone.advantagedatabase.com>
Date: Thu, 21 Jul 2011 12:38:37 +0300
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
From: "Yury Vitovsky" <yura@wgsoftpro.com>
Organization: SoftPro
Message-ID: <op.vyyqenluhx6u6k@yura.masq.lc>
User-Agent: Opera Mail/11.50 (Win32)
X-Original-NNTP-Posting-Host: yura.masq.lc
X-Original-Trace: 21 Jul 2011 12:38:34 +0300, yura.masq.lc
Lines: 84
NNTP-Posting-Host: 89.162.137.146
X-Trace: 21 Jul 2011 02:38:57 -0700, 89.162.137.146
Path: solutions.advantagedatabase.com!192.168.0.1!not-for-mail
Xref: solutions.advantagedatabase.com Advantage.FoxPro:374
Article PK: 1109728

Hi Alex, Mark,

thanks for your explanations. It's clear for me now.
But it would be nice if remark regarding this differences will appear in
the Advantage documentation in future :-)

Thanks again
Yury
=============================

Alex Wong <someone@sybase.com> писал(а) в своём письме Wed, 20 Jul 2011
20:45:29 +0300:

> Hi Yury,
>
> Increasing the field length is probably the best solution. It is not the
> decimal point that is excluded, it is the sign that is exclude. In fact,
> it is actually allowed to store 999999 in numeric 6, 2 in FoxPro. The
> xBase standard does not enforce the decimal. As long as the data fits in
> the given field width, 7 characters in this case, it is allowed. This is
> just a quirk of the DBF and best to avoid using such behavior.
>
> --
> Alex
>
>
>
>
>> Hello,
>> our customer has Visual FoxPro application and data in DBF format.
>> Now he tries to migrate this database to Advantage and gets the
>> problem
>> with NUMERIC fields.
>> - Visual FoxPro NUMERIC field have format 6,2. It's Ok for FoxPro
>> application to input value up to 9999.99 into this field.
>> - ARC32 show this format and value the same, but user can't insert
>> value
>> greater than 999.99 in this field.
>> Please find in attachment small sample table that was created in
>> Visual
>> Foxpro. See last field IZNOS_K and its value (1030.4, it was entered
>> in
>> Visual FoxPro database).
>> Please open it as Visual FoxPro dbf table by arc32 and try to edit
>> this
>> value simple by pressing F2 and Enter. You will get an error.
>> So Visual FoxPro exclude decimal point from dbf format length, but
>> Advantage DBF does not.
>> And what is the correct way to migrate this data to Advantage? We just
>> advised them to increase field length, but they have some hundreds of
>> such
>> fields and it is a bit laborious…
>> Regards,
>> Yury Vitovsky
>> SoftPro
>> Ukraine
>
>

--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/


Joachim Duerr (ADS) Posted on 2011-07-21 10:25:34.0Z
From: "Joachim Duerr (ADS)" <jojo.duerr@gmx.de>
Subject: Re: NUMERIC data type in FoxPro
Newsgroups: Advantage.FoxPro
References: <op.vyw5s11nhx6u6k@yura-note> <9d1879957b9a8ce14e9a858b171@devzone.advantagedatabase.com> <op.vyyqenluhx6u6k@yura.masq.lc>
Date: Thu, 21 Jul 2011 12:25:34 +0200
User-Agent: XanaNews/1.19.1.269
X-Face: u2p+</,mb|Ah!x!/qxX5q0t:O~.<1&JzwNHYhSqcviY{~&|iDc"U.Je1A.ZeHR`d;;y#R
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 10.29.66.130
Message-ID: <4e27fec0$1@solutions.advantagedatabase.com>
X-Trace: 21 Jul 2011 03:26:08 -0700, 10.29.66.130
Lines: 13
Path: solutions.advantagedatabase.com
Xref: solutions.advantagedatabase.com Advantage.FoxPro:375
Article PK: 1109729


Yury Vitovsky wrote:

>thanks for your explanations. It's clear for me now.
>But it would be nice if remark regarding this differences will appear
>in the Advantage documentation in future :-)

for ADT it is docuemtned:
http://devzone.advantagedatabase.com/dz/WebHelp/Advantage10.1/index.html?master_adt_field_types_and_specifications.htm

--
Joachim Duerr, Advantage Presales
*** NEW *** Advantage Pocket Guide released *** NEW ***
http://pocketguide.jd-engineering.de


Altiy Zemlytskiy Posted on 2011-07-24 06:06:21.0Z
Content-Type: text/plain; charset=koi8-r; format=flowed; delsp=yes
Newsgroups: Advantage.FoxPro
Subject: Re: NUMERIC data type in FoxPro
References: <op.vyw5s11nhx6u6k@yura-note> <9d1879957b9a8ce14e9a858b171@devzone.advantagedatabase.com> <op.vyyqenluhx6u6k@yura.masq.lc> <4e27fec0$1@solutions.advantagedatabase.com>
Date: Sun, 24 Jul 2011 09:06:21 +0300
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Altiy Zemlytskiy" <altiy@wgsoftpro.com>
Organization: SoftPro
Message-ID: <op.vy30kvpjj8q8fu@altiy-notebook>
User-Agent: Opera Mail/11.50 (Win32)
NNTP-Posting-Host: 94.179.1.133
X-Trace: 23 Jul 2011 23:06:09 -0700, 94.179.1.133
Lines: 16
Path: solutions.advantagedatabase.com
Xref: solutions.advantagedatabase.com Advantage.FoxPro:377
Article PK: 1109731

Yes, many thanks, but we are talking about dbf. It would be easier for us
to refer the specifications

> Yury Vitovsky wrote:
>
>> thanks for your explanations. It's clear for me now.
>> But it would be nice if remark regarding this differences will appear
>> in the Advantage documentation in future :-)
>
> for ADT it is docuemtned:
> http://devzone.advantagedatabase.com/dz/WebHelp/Advantage10.1/index.html?master_adt_field_types_and_specifications.htm
>

--
A.Zemlytskiy


Alex Wong Posted on 2011-07-22 14:51:01.0Z
Date: Fri, 22 Jul 2011 14:51:01 +0000 (UTC)
Message-ID: <9d1879957c018ce16639e566078@devzone.advantagedatabase.com>
From: Alex Wong <someone@sybase.com>
Subject: Re: NUMERIC data type in FoxPro
Newsgroups: Advantage.FoxPro
References: <op.vyyqenluhx6u6k@yura.masq.lc>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=utf-8; format=flowed
X-Newsreader: JetBrains Omea Reader 1098.1
NNTP-Posting-Host: 10.6.193.123
X-Trace: 22 Jul 2011 07:50:53 -0700, 10.6.193.123
Lines: 70
Path: solutions.advantagedatabase.com
Xref: solutions.advantagedatabase.com Advantage.FoxPro:376
Article PK: 1109730

Hi Yury,

If you call ACE directly, using AdsSetField() or AdsSetString(), you will
be able to store the values just as in VisualFoxPro using DBF table type.
In this regard, Advantage is no different from VisualFoxPro. However, as
Mark explained, the behavior is not condusive in higer level clients such
as Delphi, ODBC or ADO.NET. You will probably get the same behavior using
non-Advantage drivers to connect to those tables. I did not suggest using
ACE directly to read/write data mainly because of the non-standard behavior
and also because it is usually more work to modify the program.

Alex

> Hi Alex, Mark,
>
> thanks for your explanations. It's clear for me now.
> But it would be nice if remark regarding this differences will appear
> in
> the Advantage documentation in future :-)
> Thanks again
> Yury
> =============================
> Alex Wong <someone@sybase.com> писал(а) в своём письме Wed, 20 Jul
> 2011 20:45:29 +0300:
>
>> Hi Yury,
>>
>> Increasing the field length is probably the best solution. It is not
>> the decimal point that is excluded, it is the sign that is exclude.
>> In fact, it is actually allowed to store 999999 in numeric 6, 2 in
>> FoxPro. The xBase standard does not enforce the decimal. As long as
>> the data fits in the given field width, 7 characters in this case,
>> it is allowed. This is just a quirk of the DBF and best to avoid
>> using such behavior.
>>
>> --
>> Alex
>>> Hello,
>>> our customer has Visual FoxPro application and data in DBF format.
>>> Now he tries to migrate this database to Advantage and gets the
>>> problem
>>> with NUMERIC fields.
>>> - Visual FoxPro NUMERIC field have format 6,2. It's Ok for FoxPro
>>> application to input value up to 9999.99 into this field.
>>> - ARC32 show this format and value the same, but user can't insert
>>> value
>>> greater than 999.99 in this field.
>>> Please find in attachment small sample table that was created in
>>> Visual
>>> Foxpro. See last field IZNOS_K and its value (1030.4, it was entered
>>> in
>>> Visual FoxPro database).
>>> Please open it as Visual FoxPro dbf table by arc32 and try to edit
>>> this
>>> value simple by pressing F2 and Enter. You will get an error.
>>> So Visual FoxPro exclude decimal point from dbf format length, but
>>> Advantage DBF does not.
>>> And what is the correct way to migrate this data to Advantage? We
>>> just
>>> advised them to increase field length, but they have some hundreds
>>> of
>>> such
>>> fields and it is a bit laborious…
>>> Regards,
>>> Yury Vitovsky
>>> SoftPro
>>> Ukraine


Mark Wilkins Posted on 2011-07-20 19:56:42.0Z
From: "Mark Wilkins" <a@b.c>
Newsgroups: Advantage.FoxPro
References: <op.vyw5s11nhx6u6k@yura-note>
In-Reply-To: <op.vyw5s11nhx6u6k@yura-note>
Subject: Re: NUMERIC data type in FoxPro
Date: Wed, 20 Jul 2011 13:56:42 -0600
Lines: 1
Organization: Sybase
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8089.726
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726
NNTP-Posting-Host: 10.6.199.122
Message-ID: <4e2732f8@solutions.advantagedatabase.com>
X-Trace: 20 Jul 2011 12:56:40 -0700, 10.6.199.122
Path: solutions.advantagedatabase.com
Xref: solutions.advantagedatabase.com Advantage.FoxPro:373
Article PK: 1109726

Hi,

I don't have any solutions or ideas beyond what Alex wrote in his answer.
But the following provides a little bit of the rationale of why Advantage
behaves the way it does.

One of the reasons that Advantage works this way is because of the generic
clients (ADO.NET, ODBC, OLE DB, etc.) that have certain expectations about
the precision of numeric values and the sizes of values that can be stored
in a field of a specified precision. The basic problem is that if Advantage
allowed the value 9999.99 to be stored in the field, it would have to report
a precision of 6 to these generic clients. And if it reports that a
precision of 6 is allowed, then the clients also believe then that -9999.99
is a valid value, but it isn't since the field doesn't physically have room
for it. And on the other hand, if Advantage just reported the precision as
5 for that field while allowing values with 6 places of precision to be
stored, then those longer numbers cause problems in the generic client. The
client would expect that the largest valid value would be 999.99 and
possibly have problems when given a value like 9999.99.

I don't remember which of clients exactly had problems in which situations;
I only remember that we encountered a number of problems like what I just
described over the years. While the solution and restrictions we have
chosen have minimized these problems, it is obvious that it is not a perfect
solution because of the exact problem you are encountering.

Mark Wilkins
Advantage R&D

"Yury Vitovsky" <yura@wgsoftpro.com> wrote in message
news:op.vyw5s11nhx6u6k@yura-note...
> Hello,
> our customer has Visual FoxPro application and data in DBF format.
> Now he tries to migrate this database to Advantage and gets the problem
> with NUMERIC fields.
> - Visual FoxPro NUMERIC field have format 6,2. It's Ok for FoxPro
> application to input value up to 9999.99 into this field.
> - ARC32 show this format and value the same, but user can't insert value
> greater than 999.99 in this field.
>
> Please find in attachment small sample table that was created in Visual
> Foxpro. See last field IZNOS_K and its value (1030.4, it was entered in
> Visual FoxPro database).
> Please open it as Visual FoxPro dbf table by arc32 and try to edit this
> value simple by pressing F2 and Enter. You will get an error.
> So Visual FoxPro exclude decimal point from dbf format length, but
> Advantage DBF does not.
> And what is the correct way to migrate this data to Advantage? We just
> advised them to increase field length, but they have some hundreds of such
> fields and it is a bit laborious…
>
> Regards,
> Yury Vitovsky
> SoftPro
> Ukraine