Zugg Software :: View topic

Wanderer Joined: 02 Sep 2005 Posts: 85

I'm a bit confused on the wording in helpfile on either #SQLDB/%sqldb.. and it doesn't really help things when one has a shared host.. I'm trying to play with every new feature so I get an idea of how it works..

I'm using cmud pro v3 so that's not an issue with specifying db's.. I'm just getting bad variable path when I try either version of #sqldb or %sqldb, so I need a bit more of clarification :)

Posted: Tue Oct 26, 2010 8:12 pm

You'll need to show us the exact #SQLDB command that you are trying to use. Shouldn't matter if you have a shared host or not. I've tested it on a MySQL server on a shared host without any trouble. Feel free to change the username/password/hostname info in your post to protect your privacy.

Also, make sure you have the proper driver DLL file for your database server in the same directory as the CMUDPRO.EXE file.

Wanderer Joined: 02 Sep 2005 Posts: 85

Edit: NM, I figured #sqldb out, it's now returning Could not connect to MySQL server on www.testsite.net (0)?
and with %sqldb, it's returning bad variable type...(LoginPrompt)..

Posted: Wed Oct 27, 2010 5:41 pm

Several problems confirmed. Surprised this made it past the beta testing.

1) First, the %sqldb is bugged in that it expects the "name" and "database name" arguments to be the same instead of separate. The "shareduser_table" should be the name of the *database* on the server, not a specific table. But in any case, the "Mobs" argument needs to be removed since CMUD is taking that first argument as the remote database name instead of the #SQLDB connection name. Don't worry about this because of bug #2 and I'll fix this in the next update so it works as documented.

2) The more serious problem was the "db.LoginPrompt=1" line. The LoginPrompt is a COM property of the connection and has a "type" of "boolean". But CMUD handles booleans as numeric values (0 and 1). There was a low-level COM bug in CMUD that was preventing CMUD from setting a Boolean property in some cases. Normal COM variables (created via %comcreate) worked fine, but the internal COM variables created by %sqldb and %sql (and %url) had this bug. That is what caused the "bad variable" error.

In any case, I tested the following #SQLDB line and it worked:

Wanderer Joined: 02 Sep 2005 Posts: 85

Posted: Wed Oct 27, 2010 7:46 pm

Wanderer Joined: 02 Sep 2005 Posts: 85

I said that the host not allowing connections was fixed, you missed the (fixed) part, but yeah, I also missed re-reading your post about %sqldb, thanks for re-posting it again :( Sorry I'm such a pain today.. I 'unno why.. I really don't

but, this is the issue I was posting about (again) after #SQLCLOSE + re-run test alias: it says SQL server has gone away ? =( what do I do next? <- that part is giving me issues with #SQLDB

But! I am just going to end up using %sqldb, because it's far easier to open and close on demand, rather than deal with the issue of "cant perform operation on a closed dataset" or "SQL Server has gone away"..