Foreign Table

[DBohner-(db)]

Howdy!,

Ok, I am busily keyboarding away... working on File Conversions...

We realize that the guys running the legacy system - don't have the
necessary format of a date field that we need for importing to JDE. We ask
them to change the field type to date and they do so.
We log out of JDE (XE) and log back in... We edit out File Conversion UBE -
and the field has not changed. We know the data type is different, but OW
doesn't reflect any changes made to the foreign table.

Next step is to copy the foreign table to a new name... we do so.. now OW
sees the field as the correct data type.

Any ideas?

Daniel Bohner
[email protected]
www.existinglight.net

 

[Adrian_Chimirel]

Daniel,

This time, the limitation resides within that Foreign Database (let me guess, ... is it Microsoft?). I had the same problem with Access
As a matter of facts you just re-defined the whole table structure when you copied it! That made OW finally, see the (new) datatype.

Adrian Chimirel
Programmer Analyst
LIVE: B732.1 SP12.2, Oracle 806
SANDBOX: XE SP13, 8i
RS/6000, Citrix, 200+ clients

 

[DBohner-(db)]

Adrian,

And the fix would be? Our consultant is baffled ~ and it doesn't make sense
to use either. Where are the specs being kept ~ that they are not being
refreshed when the object is changed. I can create a new UBE using the
modified filespec and the unmodified spec is what's represented.

That doesn't sound like an SQL Server bug, that sounds like a JDE bug... My
links from MS Access see the change, but JDE doesn't... even when I have
deleted the local specs and had them rebuilt.

Daniel Bohner
[email protected]
www.existinglight.net

 

[Adrian_Chimirel]

Re: RE: Foreign Table

It's hard to get a fix when still not sure where the bug is ... but you already worked it around
If you consider it as being a JDE bug, why don't you ask'em? Sometimes (especially with Xe issues) they have competent answers!

I don't know where OW/TC keeps Foreign Table's Data Types definitions (somewhere close to the Data Sources?) therefore I don't have a clue where the 'frozen' specs may be found; but I'll keep that in mind for the Table Conversions training course, and I'll post useful answers.

Adrian Chimirel
Programmer Analyst
LIVE: B732.1 SP12.2, Oracle 806
SANDBOX: XE SP13, 8i
RS/6000, Citrix, 200+ clients

 

[Zoltan_Gyimesi]

Daniel, Adrian
This is one of the reason why do we use always text file for input from legacy systems.
I have developed once upon a time (under B7321) our "Convert String To Mumeric Flexible" and "Convert String To Date Flexible" Business Functions and used it several times in our GL and AR interfaces, easy extracting and converting any value from text.

IMHO, text files is the most general and simpiest data representation and it is the most flexible and easiest to modify when it is necessary, further generally all of legacy system can it produce easily (sometimes with some development).

Further, to avoid the conflict of using delimiters and place-holders, we use always fixed field length structures.

I know, it is not a remedy for your problem but maybe a little bit considerable for the future.

Regards,
Zoltán

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)