× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 15-Feb-2014 06:31 -0800, Narayanan Pillai wrote:

On 02/14/2014 01:54 PM, CRPence wrote:
<<SNIP>>

If the database file has columns with CCSID(*HEX) [CCSID=65535],
then _correct_ that definitional issue with the file *instead of*
using the kludge that is the /force conversion/ option\checkbox.

<<SNIP>>

<<SNIP>> how does one go about doing this for a packaged
application, like JDEdwards, for instance?

Quite varied possibilities, dependent greatly on the application or user requirements, but the primary option is probably going to the source to ask what is the proper resolution; i.e. to the software provider, asking how to access the data in its proper external representation without using the kludge. If they intend for the data to be accessed from those files, then they really should be providing the means to do so. That is, they should provide a means to properly externalize their data, specifically so it can be accessed outside of their application(s). Some query products have effective JDE plug-ins specifically to deal with the issue of getting access to the data in the proper external form. The JDE might [best] provide for an export or logical definitions [VIEW] of the data to provide access to the properly externalized form\representation of the data instead of the raw-form.

Otherwise, without a query adapter\plug-in feature, an exporter, or logical VIEWs, one could create the necessary logical representation of the data in their query, optionally encapsulated in a VIEW. If not encapsulated in a VIEW, composing the query for an ad hoc request would likely be a rather frustrating task for a user, so implementing the 'force conversion' option is probably a least-effort attempt at a so-called /resolution/. However if the data in its raw form is correctly stored with no-translation, then inherent in the fact that the encoding changes in that transfer scenario, is that the transferred data is incorrect. Even in a case whereby the data may appear sufficiently correct across that encoding change with [and because of the] forced translation [apparently because the data should be tagged with a non-hex CCSID], then any data is truly correct only for the SBCS character data in code points that are neither variant nor had the data originated from more than one code page *and* the settings for that user's connection doing the transfer would have to have matched the code page from which the data originated. That is a lot of supposition to entrust for one's business data. Obviously for the "time data" that was purely EBCDIC digits, as invariant characters, there is no concern. But if users change to default to 'force translation', then anybody's guess what they will eventually transfer to their client... incorrectly.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.