Your solution aligns pretty with a solution given to me by Epicor
Support. We're planning to try it soon. Thanks for the advice and we'll
let you know if we get stuck!
Support. We're planning to try it soon. Thanks for the advice and we'll
let you know if we get stuck!
--- In vantage@yahoogroups.com, DD <ddavis4569@...> wrote:
>
> Did you get the answer for this?
>
>
> In the Data Dictionary from Openedge (not the data dictionary viewer)
select the ShipTo table. Then options / adjust field width. This will
show you the length of the field sent to ODBC and the format.
> on my system 8.03.407 it shows 28 for ODBC and x(14) for the format.
> DO not change the format as that is used in Vantage but you can
increase the size of the field sent to ODBC. The default is twice the
format.
>
> Be sure you make a backup 1st and try it on a test database.
> This has to be done when no one is in the database. You can view the
field with people in the database but not change it as the database will
be locked.
>
> Contact me offline if you need help finding the correct spot for the
ODBC field length.
>
>
> --- On Fri, 5/29/09, kenjacoby@... kenjacoby@... wrote:
>
>
> From: kenjacoby@... kenjacoby@...
> Subject: [Vantage] ShipToNum Field Length Discrepancy between Crystal
11 with Vantage 8.03.305
> To: vantage@yahoogroups.com
> Date: Friday, May 29, 2009, 8:51 PM
>
>
>
>
>
>
>
>
> Running Crystal Reports 11 and get OpenEdge ODBC (Database Vendor
-Code -20152) errors while querying records where Crystal is expecting a
String(8) but Vantage data is as large as String(11) in the
ShipTo.ShipToNum field. Can anyone suggest a solution? Not sure if Open
Edge Drivers are routinely updated or how to get them and update them. I
could shorten our ShipTo.ShipToNum entries going forward as a workaround
but can't do much about errors caused by pre-existing undeletable data.
Any inputs are appreciated!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>