Please be aware that the SAP SQL Anywhere Forum will be shut down on August 29th, 2024 when all it's content will be migrated to the SAP Community.

Does anyone have personal experience with this error on a SQL Anywhere 16 database trying to load and use DLL functions via CREATE PROCEDURE ... EXTERNAL?

I'm trying to remotely debug the following error which prevents Foxhound 3 from responding to any user input in one single installation:

SQLCODE = -620, 
ERRORMSG() = Could not load dynamic library 'C:\ProgramData\RisingRoad\Foxhound3\unknown'

ALL the causes for that error (missing DLL, etc) that I know about have been eliminated. Attempts to locally reproduce the symptom have failed, INCLUDING testing a complete copy of all the installed files received from the remote site... it works fine on my computer.

asked 21 Jan '15, 10:25

Breck%20Carter's gravatar image

Breck Carter
accept rate: 20%

edited 21 Jan '15, 10:41

Volker%20Barth's gravatar image

Volker Barth

Bit of a head scratcher that!

In theory (and from a quick review of the relevant code)
'C:\ProgramData\RisingRoad\Foxhound3\unknown' should just be the dll name string passed into the gear that calls the Windows API function LoadLibrary() and it is thrown that right after the LoadLibrary( ) fails.

Since I doubt you have declared the SQL wrapper function for this that way . . . hmmmm

(21 Jan '15, 11:31) Nick Elson S...
Replies hidden

Does the customer's (now) broken database show anything in proc_defn from sys.sysprocedure that indicates the create failed on that system? And does that database throw the error on other systems ... if copied to them? (or "text" from dbo.syscomments show any odd history?)

(21 Jan '15, 11:38) Nick Elson S...
Replies hidden

Locally, the "broken" database works flawlessly. Here is what one of the CREATE PROCEDURE EXTERNAL objects looks like after being created locally (the first result set has been wrapped manually for clarity):

select * from sysprocedure where proc_defn LIKE '%rroad_get_command_line%';


create procedure "DBA"."rroad_get_command_line"( out "command_line" varchar(32766),
out "return_code" unsigned integer,out "diagnostic_code" unsigned integer,
out "diagnostic_string" varchar(255) ) \x0aexternal name 

select * from syscomments 
 where id=(select distinct id from syscomments where text LIKE '%rroad_get_command_line%') 


31738,0,1,0,0,'create procedure "DBA"."rroad_get_command_line"( out "command_line" varchar(3276',0
31738,0,2,0,0,'6),out "return_code" unsigned integer,out "diagnostic_code" unsigned integer,out',0
31738,0,3,0,0,' "diagnostic_string" varchar(255) ) \x0aexternal name ''get_command_line@C:\\\\Program',0
(21 Jan '15, 13:29) Breck Carter

For what it's worth, the word "unknown" has been known to appear in this error message when the dll is missing from the folder. This makes me think that something mysterious is broken in the SQL Anywhere 16 installation... is there any mental equivalent of a dead chicken that might suggest to you what might cause this?... the failing foxhound3.db files works just fine when copied to my computer (I know it is the failing database because Foxhound has dutifully saved about a thousand of those error messages in its own diagnostic table).

(21 Jan '15, 13:35) Breck Carter

Thanks very much for the suggestion... I hope to get the query results from the broken installation.

(21 Jan '15, 13:37) Breck Carter

We parse that dll's FQN from that entry ... so something must be going wrong there. You might want to capture OS and C runtime library (version) information while you look into that at the site.

FWIW I've been looking through that code and it does not seem to be something that has changed much on this end.

(21 Jan '15, 14:36) Nick Elson S...
Replies hidden

The "unknown" substring is a red herring... it is coming from the application after it makes two successive failed calls to an external procedure, first using a 32-bit DLL and then using a 64-bit DLL. The purpose behind these two calls is merely to determine which DLL should be used. Sadly, the application does not capture ANYTHING about those two failures, but just uses "unknown" as the dll name for all further external procedure definitions... a huge design flaw that has gone undetected for many years. Until now, the two initial calls have both failed ONLY when the dll files are missing, which is not the case here.

A diagnostic patch has been delivered, with hope that it will be applied :)

(22 Jan '15, 11:08) Breck Carter

Nick, while I wait for further diagnostics, can you think of anything one could DO to a Windows 2008 R2 and/or SQL Anywhere 16 2052 installation that would PREVENT an EXTERNAL procedure call from working?

(22 Jan '15, 11:15) Breck Carter
Replies hidden

Just a very wild guess: Missing permissions on the DLL? (Though that might raise a different error, I'd expect...)

(22 Jan '15, 11:28) Volker Barth

Do we know if this is new behavior to just build 2052? Or even version 16? {I've been looking for all possible changes but knowing that may help narrow this down some}

As to V16 related changes, there could be a few differences to earlier versions such as: the sql security invoker clause default, a couple of new security features (-sf )around disk sandboxing, roles (of course ... and/but did the customer implement dbinit -pd? or use an older file format?), all in addition to the basics around execute permissions and credentials of the calling "chain".

None of which I believe interact in this way ... but do prove me wrong ... it could only help.

(22 Jan '15, 11:39) Nick Elson S...
Replies hidden

Volker and Nick: Thanks! The lack of diagnostics on the original error makes all your suggestions possible (except dbinit -pd since the physical database file was created by me). This is an environmental thing since a copy of the failing database file works OK on my computer.

(22 Jan '15, 13:57) Breck Carter

I too have been tossing around possible ideas concerning permissions but I could not see how that could cause that 'unknown' to show up; the first time directory access or permissions come into it is immediately after the call to LoadLibrary() and that is not returning that (or any other) string.

That is what is leading me think there is some MSC library or shim or virus involved somehow.

The fact that the string 'u'-'n'-'k'-'n'-'o'-'w'-'n'-'e'-'d' harkens back to some old (V7-ish) behaviours also does not seem to come into it since it is part of a(n otherwise) whole string that has that substituted. Whole strings can be 'unknown' if some look up of text fails, but that's not the case in this scenario either.

Of course, infected software can always be doing something else . . .

(22 Jan '15, 14:40) Nick Elson S...

sorry sorry sorry sorry sorry (that's five "sorrys", the maximum possible)... the "unknown" is a red herring, it comes from my application after it fails twice to call one of the EXTERNAL procedures... see my comment above for more information. I am currently waiting for more diagnostic information.

(22 Jan '15, 16:47) Breck Carter
More comments hidden
showing 5 of 13 show all flat view
Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 21 Jan '15, 10:25

question was seen: 2,464 times

last updated: 22 Jan '15, 16:47