Hi Jack and TY,

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.

Hi,
To connect with the Microsoft SQL, do we need to use the ODBC connector?
If so, where do I get the DLL ?

Thanks

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

Many thanks my friend

I grabed the command they execute in Excel to take data from the same SQL database (ok, the password is also there )

DRIVER=SQL Server;SERVER=BTC-PMV\PRIMAVERA;UID=sa;PWD=CATMJER!123;APP=Microsoft Office 2003;WSID=SERVER;DATABASE=PRIBIT;Network=DBMSLPCN;Address=\\BTC-PMV\pipe\MSSQL$PRIMAVERA\sql\query

Can you confirm, for ASQL, what goes in host and schema?

host = BTC-PMV\PRIMAVERA
schema = PRIBIT

Hi Jorge,
I just have these set:

[Connection]
Host=maSQL
DBMSID=2
Schema=
PW=
User=

Where maSQL is the name I called it in ODBC..

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.

sqlx.sub

Jorge -

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.

thanks in advance

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.

Thank you Steve

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 ...


Does that answer your question?

Note that the libashodbc.dll,like the rest of A-Shell, can be shared among all the RDP users.

Oh!

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?


Many thanks

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.

Good morning,

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.

Thanks in advance

Hi Jorge,

Nothing like a mystery to start the week!

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.