Getting "SQLExtendedFetch failed" errors when running UBE over a custom view/table

[DaRogue69]

Getting \"SQLExtendedFetch failed\" errors when running UBE over a custom view/table

All,

I'm trying to troubleshoot an error we receive while running a custom UBE that selects data from a custom view/table that resides in another database.

Here's what we setup:

1) Create a JDE Table that consists of new/custom DDict items, mostly numeric fields and some text (created as VarStrings).
2) Generated the Custom Table and Indexes.
3) Going into SQL Server Management Studio, we delete the table created from step 2.
4) We create a new SQL View that maps data from another SQL database into the custom JDE table. Fields are mapped individually. The name of the new View is F58TAPB2.
5) If you run a query against the custom table, F58TAP2, all rows are returned - approx. 275 - and appear to be populated correctly.
6) Created a JDE BSVW (V58TAPB2) to reside over the custom F58TAPB2 table.
7) Created a Custom UBE that pulls all records from the V58TAPB2.
8) JDE report runs and pulls data, but only the first 100 or so records are getting pulled.
9) Looking in the JDE.LOG file, I see the following errors:

3868/2408 MAIN_THREAD Tue May 18 15:33:38.350000 Jdb_ctl.c3946
Starting OneWorld

3868/1140 WRK:Starting jdeCallObject Tue May 18 15:34:02.284000 Jdekprnt.c1088
KNT0000119 - PRTTable_GetDefaultPrinterInfo failed to find printer: User: DAROGUE69 Host: WinClient

3868/696 UNKNOWN Tue May 18 15:34:04.302000 Jdekprnt.c1088
KNT0000119 - PRTTable_GetDefaultPrinterInfo failed to find printer: User: DAROGUE69 Host: WinClient

3868/696 UNKNOWN Tue May 18 15:34:05.151000 Odbc_p1.c1679
ODB0000092 - SQLExtendedFetch failed. Table(1st) F58TAPB2, ODBC DSN HILE1DB01.

3868/696 UNKNOWN Tue May 18 15:34:05.151001 Jdb_drvm.c1176
JDB9900172 - Failed to execute db fetch

3868/696 UNKNOWN Tue May 18 15:34:05.421000 jdepref.c208
GetRecipientPreferences :No email address found for contact, assuming workcenter email an8<167839> idln<0>

3868/696 UNKNOWN Tue May 18 15:34:05.421001 jdepref.c208
GetRecipientPreferences :No email address found for contact, assuming workcenter email an8<167839> idln<0>


We're running E1 8.12/Tools 8.98.2.4 over SQL Server 2005.

We couldn't find anything specific on the Oracle Support website except a reference that if you used STRING datatypes instead of VARSTRINGS - this could happen. We actually wrote everything first as STRINGS, then created a second table using VARSTRINGS, but the results are identical.

Does anyone have any ideas on what we could try next? Any help or suggestions would be greatly appreciated!

 

[tfall]

Re: Getting \"SQLExtendedFetch failed\" errors when running UBE over a custom view/table

We have a similar issue, did you happen to get a solution? Thanks

 

[DBohner-(db)]

Re: Getting \"SQLExtendedFetch failed\" errors when running UBE over a custom view/table

Generally, E1 might be faulting when the value of one of the fields does not correctly relate to the data descriptions (an alpha in a numeric???)...

In SQL, sort/sequence the data the same way it is in your Virtual Table and/or Business View. Then go about 100 (or so) records down and check to see if 'one of these things is not like the others'.

SQL can be more and less flexible - but, once the data starts getting piped into the applications the Data Dictionary setup has to be more specific. You may have to run the ube in debug, to catch the initial offender.

Additionally - here are some things to look out for:
- Never CROSS Libraries
- Use Debug to capture the Select Statement (so you can verify it looks correct)
* Sometimes you accidentally create copies in the wrong locations!
- Run the SQL Statement (as captured from Debug) to validate the data is correct
- Run the BSVW in Databrowser (to validate that E1 is looking at it correctly)
- Don't be afraid to ask for help.


Since the original design was VARCHAR instead of Strings - Delete the table from within the toolset (not from the SQL Command Line). This is the SURE way to know that it was deleted from the same location it was created.

For Foreign Tables - WHENEVER POSSIBLE - OCM to the FOREIGN LOCATION (Don't create the Virtual Table in PRODDTA and have it point to a foreign location. Create it in the FOREIGN Location and OCM TO IT)

(db)