We have created a virtual machine to experiment with SQL and Ashell. When we set it up it said our connector was expired. Is there a newer one available?
ERROR MESSAGE
SQLTEST1 - Verify existence of A-Shell/SQL connector and database client library
Select database connector (1=MySQL,2=ODBC) [1] 2
Using connector ODBC Loading connector and client library... [DBMS error #-98765 (Beta connector has expired; contact MicroSabio for update)] Connector or client library failed to load. If cause is not clear from error(s) list above, consult the troubleshooting section in the A-Shell/SQL documentation.
Sorry for the slow follow-up here. I was on the road last week and apparently the automatic forum notifications weren't getting to me.
All of the connectors released during the beta period had an expiration data hard-coded into them, just to make sure that people didn't keep running with the beta version.
Ty will send you a new (non-expiring) connector. If anyone else runs into this, please email Ty directly.
You need both. I'm having difficulties connecting to the distribution site right (maybe down for maintenance?) so I emailed you the libashodbc.dll.
You also need to define a Data Source using the Windows 32 bit ODBC tool (just enter ODBC32 in the search bar to find it). I think you can use any of the variations for SQL Server.
ASQL will connect to the data source you create, so it's ashw32 -> libashodbc.dll -> SQL Data Source -> SQL Server.
You'll also probably need an update to your A-Shell license to add the ASQL support.
Hi Jack. Thank you for the email with the DLL. Since yesterday that I'm in the middle of family/friends meetings so, not enough quiet and time to study all the details and I'm leaving here where I am in case you have some clue in advance.
I've configured the ODBC with success, but still receiving an error in your SQLTEST1. Is the error message normal or do I still need to setup more stuff?
I was going to try your sqltest2, but it's missing the fnsqlckver.bsi to compile it.
Don't interrupt anything in your weekend leasure because of this, instead, enjoy the best, I will be in a barbecue/pool party almost all day so, no hurry
Jorge Here's a link to my bunch of SQL function statements in use in my subroutine SQLX.SUB mostly just tweaked extracts from Jack's examples. They MAY help and hope they dont just confuse matters.
I emailed you the missing bsi (although it's not at all essential for our purposes here).
I'm not quite sure of the interpretation of the Excel options, but it doesn't appear that it actually uses the ODBC data source.
ASQL relies on the ODBC datasource definition, which encapsulates all of the relevant details about the database server. According to your image, you've named your datasource "asw", so your connection command would look something like:
Note that you don't need the -db argument for the connection. (You can specify the default database as part of the ODBC definition.) Also note that the "Connection Not Open" message you see in the SQLTEST1 is not really a problem. (The program doesn't attempt to establish an actual connection, and in this case the info query is just returning that piece of information in the response.)
Now everything makes sense, the ODBC Data Source Administrator handles the connecion with the SQL and A-shell talk with him using the name I've defined there. Many thanks Steve and Jack, you made my day.
Again, many thanks for the clarification, Steve and Jack, after your tips everyhting become clear and it's working great. Now I have one doubt regarding the global environment and appreciate for the SQL experts advise.
My environment is Windows Server accessed via RDP. Does the ODBC Data Source setup must be done for each Remote Desktop User?
I know I can use Group Policies to setup that in ActiveDirectory, but considering the number of users it's easier to setup for each one, I just want to know if there is any trick to make one setup Global for all users.
I'll imagine your need the ODBC setup on each PC of that execute the ashw32.exe (but there maybe easy trick?)
We are currently only using the Window/Ashell SQL in a 1 user mode with the same program running 24/7 it connecting to our Linux/Ashell data over samba: 1) Overnight does full ashell data files extracts and refreshes SQL tables of similar name/structure. 2) During the day it uses the Ashell/Hooks to apply ashell data record changes to the relevant SQL table.
I think it's just a matter of selecting the "System DSN" tab in the ODBC Data Source Administrator to define connections that are shared by all users ..
In the SQLTEST2 program, if you select the ODBC connector, there is an option of whether to list the data sources for the current user or system ...
Code
! [107] For ODBC, ask list the data sources
if cmdhdr.dbmsconid = DBMSCONID_ODBC then
input "List Data Sources? (0=No, 1=All, 2=All User DSNs, 3=All System DSNs) ",n
if n = 1 then
cmdhdr.opflags = SQL_FETCH_FIRST
elseif n = 2 then
cmdhdr.opflags = SQL_FETCH_FIRST_USER
elseif n = 3 then
cmdhdr.opflags = SQL_FETCH_FIRST_SYSTEM
else
cmdhdr.opflags = 0
endif
cmdhdr.rc = 0
if cmdhdr.opflags then
do
xcall SQL, SQLOP_DATA_SOURCES, cmdhdr, source, infostring
if cmdhdr.rcext = SQL_NO_DATA then
? "----(no more data sources)----"
exit
elseif cmdhdr.rc then
call Show'SQL'Status(cmdhdr)
exit
else
? " ";source;tab(25);"(";infostring[1,50];")"
endif
cmdhdr.opflags = SQL_FETCH_NEXT ! switch to NEXT after initial call
loop
endif
Does that answer your question?
Note that the libashodbc.dll,like the rest of A-Shell, can be shared among all the RDP users.
That completely answer my problem, case solved for the RDP access. Anyway, just to be clear, for those accessing via peer-to-peer network, I have to configure this on each computer, correct?
Generally speaking I think that with P2P you may have to individually set them up.
However, there is also a "File DSN" option in the ODBC Data Source Administrator, which at the very least allows you to save the configuraiton and export/import it to other computers. I haven't really experimented with it but it appears that you may be able to set multiple PCs to point to a shared directory containing shared DSNs, which may have the desired effect of allowing you to add/change the DSN info without having to modify each PC.
In a Windows Server I'm geting the error on the image. I have the ODBC connector configured and the "test connection" returns OK. The connector on this server is configured like the connector in every workstation and, on the workstations I don't get the error. This server is where A-Shell is installed. On another windows server, where the SQL database runs (to where the ODBC connector points), running A-Shell from there, I also don't get the error.
I'm asking just for curiosity, because I would like to know the reason, this is not a real problem considering that it works on the workstations where A-Shell is used for real so, if there is no quick answer or suggestion, don't waste time on this.
When you say that the server is where A-Shell is installed, are the clients accessing that installation of A-Shell via a P2P connection? Or something like an RDP connection? It seems like it shouldn't matter for the loading of the libashodbc.dll (which needs to be in the bin directory along with the ashw32.exe), but perhaps there is some difference in the dll search path between the two configurations?
If the issue is related to the dll search path, then it should equally affect libashnet.dll, which you could test by calling HTTP or CRYPTO or FTP2.
If the one dll loads ok but the other doesn't, then my suspicion would turn to there being a dependency between libashodbc.dll and some Windows module. The DLL though doesn't have an explicit dependencies other than the standard Windows core modules, but perhaps if you have an older version of libashodbc.dll (prior to 1.6.122) then maybe it connects with an older version of the VC runtime package? You can download the 1.6.122 version from libashodbc-1.6.122-w32.zip
Back to the search path... there have been a few situations in the past where the normal DLL search patch didn't work for certain configurations/environments, leading us to support two additional locations for the DLL:
%MIAME%\PermCache
%PROGRAMFILES(X86)%
If it doesn't find the dll in the normal search path, it will then try each of the alternate locations. (And it will add a message to the ashlog about it.)
So if you run out of more productive things to do before Happy Hour begins, this should give you a few ideas of ways to fill the time.
Hi Jack, Correct, the Windows workstations and Windows Server where the call of libashodbc works fine are calling A-Shell in P2P mode. To move away that variable, I ran A-Shell in the local server (the problematic one) using the UNC path with IP (\\10.0.0.201\platuz\bin\ashw32.exe) instead of c:\platuz\bin\ashw32.exe, but nothing changed. Apologize, I should have mentioned it in the previous post, yes, in the ashlog I get the failed search path (see the image), but I tried with a copy of libashodbc.dll in the %programfiles(86)% and didn't work. I believe this is somehow related to some missing module or local permissions in this Windows Server, I even tried to register the DLL and that also failed so, unless you have any other clue and want me to try something, just say. Thank you very much.
I have to agree with you that it seems somehow related to a missing module or local permissions on this Windows Server. But it's unclear what the exact problem is. I can make a few clarifications though:
1. It's not necessary to register the DLL -- that's only for COM modules which this is not.
2. The mysterious reference to libashodbc-16 in the log is something I added when we made the transition from the 1.5 to the 1.6 version of the DLL. The idea was to allow two versions of A-Shell (and two corresponding versions of the libashodbc.dll to co-exist). Other than the extra lookup, it's not significant.
When you set up the ODBC data source on the server, were you using the 32 bit version? You would definitely need to use that version (otherwise it defaults to the 64 bit version); I don't think it would matter to the loading of the libashodbc.dll, but would eventually prevent you from connecting. On the other hand, it you did successfully create a 32 bit Data Source, that would presumably indicate that all of the necessary ODBC-related modules were present. (It wouldn't rule out privilege issues though.)
Did you try running one of the ashnet.dll subroutines (just to verify that DLL loading works)? If you downloaded the EXLIB, one of the easier ways to test this would be to run CRYPTO[908,55]. (Option 1 would be enough to verify that the DLL was loadable and executable.)
I wonder if the Windows Event Log has recorded an error related to this?
Hi Jack, Also the CRYPTO dlls fail to load and, I didn't found anything related to this in the Windows Event Viewer. Yes, I've configured in the 32 bit connector and if I open the 64 bit connector, it's also there but I can't edit it.
Did you solve the LIBASHODBC; Load Library Error (err #126)?
We have just restored a previous install of Windows Ashell/SQL (the whole folder and contents) as their previous server went kaput, Ashell and all runs but soon as you try Ashell/SQL we get this message. All files look there and I think I set up the ODBC the same (or looks same as my PC here)
Solved: I downloaded and install ash-6.5.1726.0c.exe elsewhere as a new install (I guess this registered DLLs and all) after that the Ashell/SQL all worked.
We've recently run into a couple of cases of failure to load the ashnet.dll, which eventually was resolved by the discovery that there was an unsigned copy of the DLL in the distribution package. Apparently some update of Windows, or more likely an anti-virus package, started blocking the loading of unsigned DLLs. So the first thing I would check in a mysterious DLL load failure like this is that the DLL has a digital signature (in the Properties). If not, replace it with one that does:
Interesting, as installing ash-6.5.1726.0c.exe (in a new/fresh folder not touching the current install) fixed the ashellsql dll not found issue, so i thought was part of registering, maybe it was part of the c distribution thingy im sure i saw pop up for a microsecond as i blinked.
I think what happened was that a later distribution contained a copy of ashnet.dll that wasn't signed. (The signature gets added during the build operation, but sometimes the signature service on the web isn't working and I fail to notice, because on my machine, for whatever reason, signatures appear to be optional.)
)
![[Linked Image]](http://www.microsabio.net/ForumImages/odbc.png)