Mobilink: getting the following error when synchronizing : ORA-01740

[Former Member]

[-10002] Consolidated database server or ODBC error: ODBC: [Sybase][iAnywhere Solutions - Oracle][Oracle]ORA-01740

= the exact error: This seems to be a missing quotes error from oracle but I can't find the cause.

---

I have sql anywhere 12 mobile db + oracle consolidated database

steps to produce this issue:

• I copied an existing and working 'consolidated database script package' and changed the version number in it. Run it and commit. no errors
• run ML_ ADD_ Missing_ dnld_scripts for the new version number => procedure executed succesfully
• restart Mobilink Service
• Update mobile database publication scriptversion number.
• Run synchronization

Result => ORA-01740 error on a seemingly random table download_ delete_cursor

• downgrade scriptversion number in mobile database
• Synchronize => success

Anyone has ever seen something like this? What could be causing this?

steps to troubleshoot:

• add: "-vt -o mlsrv12.txt" in order to see the sql of the problem:
• result: I. 2014-04-07 13:36:26. <1> Translated SQL: CALL "vdc6.1.3".DOWNLOAD_DELETE_CURSOR_WEC (:p1, :p2)

Some tips would be appreciated.

EDIT: Here is the log file:

https://drive.google.com/file/d/0B_OMCdXJPjZuVjVzS0NXUmlqWFE/edit?usp=sharing

I checked with someone who has some more experience in this and he doesn't see what's wrong...

the ML_ TABLE_ SCRIPT seems to be filled correctly so we replaced the failing script

this is failing => {CALL "vdc6.1.3".DOWNLOAD_ DELETE_ CURSOR_WEC (?, ?)} with the code that it actually calls (with hardcoded parameters) and this seems to work.

---

the previous package version "vdc6.0" works perfectly and has the exact same script in it.

So we are starting to think there is some sort of a Character Encoding issue here with the quotes.

So the next stap is to replace the download_ delete_ cursor from version vdc6.1.3 with the one of vdc6.0 ..... We thought this would fix it, but unfortunately the same problem remains...

The only thing, I can think of is that maybe the encoding of my IDE (toad) is somehow hurting the script.... or something is just broken.

Thanks for reading this and your advice,

[regdomaratzki]

Can you post the mlsrv12.txt file? It's difficult to diagnose a problem with just a single line in the MobiLink Server log.

[Former Member]

Just Editted with all the details I have.

[regdomaratzki]

Still not sure what's going on here. Could you post MobiLink logs with -v+ that show a successfull synchronization with the "vdc6.0" package and a failed synchronization using the "vdc6.1.3" package?

Thanks, Reg

[Former Member]

I've seen your question and have created the logging but has a ton of business data.

I am closer to the problem though (I hope), since someone else recreated the script-package and the synchronization does work now. Unfortunately after a file compare the two script-packages look exactly the same, except for version number that's different.

I'll come back to update you guys once we figure things out.

[regdomaratzki]

Instead of using -v+, you can use -vcefhkmnopstu, which is all verbosity switches except those involving data.

[VolkerBarth]

-vcefhkmnopstu, which is all verbosity switches

Wow, that the most "verbose" switch I've ever seen...

[Breck_Carter]

> except for version number that's different.

That might be a critical difference since the version number is used in the procedure owner name which means it depends on the existence of an Oracle user and the correct contents in that particular procedure.

CALL "vdc6.1.3".DOWNLOAD_DELETE_CURSOR_WEC

When you make use of procedure calls in MobiLink, AND use different script versions, configuration control becomes VERY difficult, VERY error prone. Comparing MobiLink scripts is not sufficient, you must compare procedure code... AND it is very easy to create accidental differences between what's in your procedure script files and what's actually stored in Oracle.

[Breck_Carter]

> the most "verbose" switch I've ever seen

ha ha... you have led a healthy and happy life indeed; here's an excerpt from a dbmlsrv9 template...

REM -v cfhnprstu logs everything - VERY LARGE
REM -v cfhnpstu  logs everything interesting except row values
REM -v cfnps     suggested for production, high volume tests

and from mlsrv16...

REM -vcefhikmnopqrRstuU  all options (some redundancy)
REM -vcefhkmnopstuU logs everything except data and remote ID

I keep forgetting that -v+ includes data, which violates The Watcom Rule because nobody EVER wants to see the data, it's like drinking from a firehose 🙂

[Former Member]

I guess you are right that the versionnumber/scriptname is a cause of my problems....

I just took the last successfull script called "vdc6.2" and all I did was replace the scriptname and this is the result:

replace scriptname with “vdc6.2.0.1” => sync fail

“vdc6.2a” => fail

“testt6.2” => success

“testtt6.2.1” => fail

“testtt6.2” => success

“vdc6.3” => success