Hi!
I can connect with isql, but i can’t connect from xojo cgi on debian 8 64bit using ODBCDatasbase.
When i use db.DataSource="dsn=girassol" it crashes the application.
Complete information with all details, here!
Any help will be very usefull
What happens with just db.DataSource="girassol".
I usually name my DSN’s something unique to prevent confusing myself.
Crashes the application
Sorry, but it’s completely absurd that I need to use a third-party plugin instead of getting help from XOJO.
I’ve been a customer since the mid-1990s, when I bought my first REALbasic.
It is unacceptable.
You know what I feel? That XOJO does not solve the problems for you to sell your plugins.
Sorry for the sincerity, but it is exactly what it seems.
Did you report via Feedback to tell them?
[quote=429710:@Alexandre Cunha]Sorry, but it’s completely absurd that I need to use a third-party plugin instead of getting help from XOJO.
I’ve been a customer since the mid-1990s, when I bought my first REALbasic.
It is unacceptable.
You know what I feel? That XOJO does not solve the problems for you to sell your plugins.
Sorry for the sincerity, but it is exactly what it seems.[/quote]
To be fair, most unix users that I’ve encountered use MySQL or PostgreSQL because (like Linux) they are more “compatible” with open source software (more PostgreSQL than MySQL these days though).
I just did a quick search in Feedback and I see no cases referring to UnixODBC or ODBC running on Linux, so while I understand your frustration, we don’t have a lot to go on here. Even a crash report would help.
Looking back at your other thread though, you should note that these two things do not represent a crash:
db.DataSource="dsn=girassol" // it crashes the application (get error 500)
db.DataSource="Driver={ODBC Driver 17 for SQL Server};" // it crashes the application (get error 500)
If your app were truly crashing, you wouldn’t be getting the Error 500, you’d be getting a blank page saying that the browser couldn’t connect. The error 500 is actually coming from the app and is usually connected to an Exception.
These lines are very telling though:
error:[iODBC][Driver Manager]{/etc/odbcinst.ini}: cannot open shared object file: No such file or directory
or if
error:[iODBC][Driver Manager]{/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.3.so.1.1}: cannot open shared object file: No such file or directory
They point to a misconfiguration of some sort. Like for instance, have you verified that those files actually exist on your Linux configuration?
Also, does your web server have permission to access those locations? Remember your app runs as whatever user your web server is, so if the software is Apache, then the apache user must have access to everything the app needs to run.
Speaking of exceptions, do you have the App.UnhandledException and/or Session.UnhandledException events implemented? If so, do they log the exceptions to a file where you can look at them?
Another idea might be to remote debug to the linux box and then try to connect to the debugged app. It might show you exactly where the problem is.
[quote=429772:@Greg O’Lone]To be fair, most unix users that I’ve encountered use MySQL or PostgreSQL because (like Linux) they are more “compatible” with open source software (more PostgreSQL than MySQL these days though).
I just did a quick search in Feedback and I see no cases referring to UnixODBC or ODBC running on Linux, so while I understand your frustration, we don’t have a lot to go on here. Even a crash report would help.[/quote]
Hi Greg! I’ll reply each posts individually.
- I undestand your considerations about “mysql and postgre”, but i do not decide the client’s option to MSSQL.
- I explain ALL my problema on https://forum.xojo.com/53027-odbc-connecting-problems
- I didn’t open a feedback case, because i think this is not a bug, it’s a configuration problem than i can’f figure out because there are no examples / documetation on xojo
- If the company develops and makes available a tool (ODBCDatabase) that has the ability to do a certain function (connect to “any” odbc), the company needs to explain how this configuration should be done, “even if it is used by 0.001% of users”, otherwise they do not offer the tool …
And yes, i CAN open a feed back case, if this will help me to “just” connect to mssql using ODBC
Alex
[quote=429774:@Greg O’Lone]They point to a misconfiguration of some sort. Like for instance, have you verified that those files actually exist on your Linux configuration?
Also, does your web server have permission to access those locations? Remember your app runs as whatever user your web server is, so if the software is Apache, then the apache user must have access to everything the app needs to run.[/quote]
[b]Greg, as i posted on other thread, the complete step by step, executing the isql -v girassol alemac xxxx i CAN CONNECT to MSSQL
So, the “girassol” DSN it’s ok!![/b]
[quote=429776:@Greg O’Lone]Speaking of exceptions, do you have the App.UnhandledException and/or Session.UnhandledException events implemented? If so, do they log the exceptions to a file where you can look at them?
Another idea might be to remote debug to the linux box and then try to connect to the debugged app. It might show you exactly where the problem is.[/quote]
No, i dont’ have any exceptions. I can implement, of course. Could you please tell me the best and fast way to do that?
And about remote debug, as i asked on a previous thread, lacks documentation.
I never could in fact debug a cgi on a remote server, ONLY on local server.
So again, please, tell me what’s the best way to trace exceptions.
Plese, if you did not read ALL my previous thread, please do it.
[quote=429873:@Alexandre Cunha][b]Greg, as i posted on other thread, the complete step by step, executing the isql -v girassol alemac xxxx i CAN CONNECT to MSSQL
So, the “girassol” DSN it’s ok!![/b][/quote]
Bold text is not necessary, I can read regular text just fine.
The fact that you can connect with a command-line is inconsequential if you are not running as the web server user. The permissions to access files on the hard drive are almost certainly less than any user that you would be using to run tests.[quote=429876:@Alexandre Cunha]No, i dont’ have any exceptions. I can implement, of course. Could you please tell me the best and fast way to do that?[/quote]
As I said, App.UnhandledException or Session.UnhandledException. Have those methods write the contents of the Stack array to a file.
https://documentation.xojo.com/getting_started/debugging/remote_debugging.html
Remote debugging on a remote server will require a VPN or other tunneling capability.
A feedback case with a sample project would certainly be helpful. We sometimes find that “the devil is in the details” so to speak, and that seeing what a user is trying to do gets us a lot closer to understanding what’s wrong.
[quote=429903:@Greg O’Lone]Bold text is not necessary, I can read regular text just fine.
The fact that you can connect with a command-line is inconsequential if you are not running as the web server user. The permissions to access files on the hard drive are almost certainly less than any user that you would be using to run tests.
As I said, App.UnhandledException or Session.UnhandledException. Have those methods write the contents of the Stack array to a file.
https://documentation.xojo.com/getting_started/debugging/remote_debugging.html
Remote debugging on a remote server will require a VPN or other tunneling capability.
A feedback case with a sample project would certainly be helpful. We sometimes find that “the devil is in the details” so to speak, and that seeing what a user is trying to do gets us a lot closer to understanding what’s wrong.[/quote]
Sorry for the bold I thought you were without the glasses 
Ok. if command line connect it’s not “proof of nothing”, no problem at all. ok. i accept that!
-
What’s the (minimum) values i need to setup on ODBCDatabase on xojo?
-
If the permissions are wrong, what are the correct permissions for /etc/odbcinst.ini or /opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.3.so.1.1? Beacuse both have read access
[edit: i changed both to 777, same problem]
Alex
hey, is your app 32-bit or 64-bit?
Linux 64bit, CGI 64bit
Ok. Just wanted to make sure since the ODBC driver is 64-bit as well.
-
What’s the (minimum) values i need to setup on ODBCDatabase on xojo?
-
If the permissions are wrong, what are the correct permissions for /etc/odbcinst.ini or /opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.3.so.1.1? Beacuse both have read access
No exception error at all.
If i point to DSN, it just go to nowhere it’s like a blackhole connection
It’s like xojo wants to connect to dsn and could not. “ok”.
but no error? nothing?
I dont know if it’s permissions, if it’s bad syntax