B4700230 - Delete or Copy Flat File

[DBohner-(db)]

I have an interesting issue on an Intel / Windows system - maybe one of you have already resolved the issue and would kindly share.

A UBE uses "B4700230 - Delete or Copy Flat File" to copy an inbound file to an archive location. When the test version is run from the Developer Client, the file copy works as expected.

However, once the UBE / Version are submitted to the server, I am getting an error 1750 from the B4700230 - and I'm somewhat baffled. Oracle defines the error as "1750 - Failed to write a new flat file"

Another thing I noticed, while shopping through the Local logs and comparing against the server logs is that the Locally Run version is doing some sort of encoding / conversion - when the copy occurs.

The following snippet occurs for each line in the flat file, between the IN-> / OUT-> dumps of the function (on the Local Run, only)
"Encoding cp1252 found in cache for user DBOHNER, environment DV900, application UBEName, version DRBTEST"

The encoding does not occur on the server-side submissions.

Would this be an issue with Unicode setup or an issue with Character ID configuration on the Enterprise Server?

The only setting in P93081 is:
User - *Public
Environment - *ALL
Program ID - *Default
Version - *Default
Encoding - CP1252
Status - AV

I think I've identified that the issue is not a Permissions Issue.

Local Develop Client is 32bit Xp Machine
Enterprise Server is 2008/64bit

(db)

Any thoughts?

 

[craig_welton]

Hi Daniel,

Do you know what line in the C file is throwing the error? (should show in the debug log) The 1750 messages only happen when a jdeFopen fails and wouldn't have gotten to the read/write operation. Also, the error is thrown if it can't open the original or new file, so the line would let us know which one it is.

Craig

 

[DBohner-(db)]

Craig,

I haven't capture a Server Log that gives me the specific line of the function where the 1750 is thrown. I'll try to gets something more specific.

The Submitted UBE's log doesn't display an error line - only Function's Dump (In and Out)

Being that the server is 64bit Windows - is there anything special that would need to be configured in the INI or the P83091 for a specific code-page / character set? Wondering if this is setup or a tools problem.

Thoughts

(db)

 

[craig_welton]

The fact that it fails on the jdeFopen seems to point to permissions or a typo in the directory structure. Surprised about the missing JDERROR message in the debug log. Can you post the debug log?
Is the location you're reading / writing from accessible to the user that starts the JDE services?

Are you using other flat file functions without an issue?

 

[DBohner-(db)]

I am new to this client - so I'm unaware if other server based Flat-File-Operations are having issues.

I know it is not a file location / typo issue - since everything is Processing Option driven and the Version that does not work on the Server works correctly on the Fat Client.

That said - it comes down to two paths from my logic. Either the Server's service / user doesn't have authority or there is a difference in CCSID Conversion between the server and fat client.

Ugh...

(db)

 

[craig_welton]

I'm betting the service user doesn't have access to the folder you're referencing. Is it a network share? A local user may not have access to that. Since no data is even being read (jdeFopen fails) I don't think you're at the point where a CCSID issue could occur.

Back to the error not showing in the debug log ... any chance you are setting cSuppressErrorMessage to 1 when calling the function? That will skip the jdeErrorSet and get nothing in the log.

 

[DBohner-(db)]

I think we can call this one resolved.

E1 Services were being started with a Local JDE Account. Once we change from the Local Account to the Domain\JDE account - we were able to copy the flat correctly.

It just takes longer to ask the right set of questions, as one gets a little older.

Thanks Craig.

(db)

 

[craig_welton]

Glad to hear it's working. Got bitten by that one as well.

Craig