My ISP will not give me the apropriate CREATE TEMPORARY TABLES rights i would need for the new roster. can cause too much serverload they say. i might look for a new host, but that might take a while and since i have paid for a year in advance...

Tried looking for a remote SQL but could not find anything.

is there no other way? do you really have to use CREATE TEMPORARY TABLES?

I am not sure, but I guess that a lot of ISPs will not allow CREATE TEMPORARY TABLES in their databases. So maybe you can make this work differently?

If not, its the end of a long relationship full of struggle and hard earned love... no more roster for me

As I said in another post, we are working on a way to cache the table data in a file and use that to backup and restore the table

Don't loose hope yet!

Hooray! Send out the dwarf to proclaim a possible future life! Get Honey and Dew and lets celebrate by liking it of the belly of nude fairies! Hooray!

keep me posted please, will ya? madness is closing in...

DaarianneDarkmoon wrote:...
I am not sure, but I guess that a lot of ISPs will not allow CREATE TEMPORARY TABLES in their databases. So maybe you can make this work differently?

I do get your point, but... I did a hunt down for questions related to this issues, and there aren't many (if any) questions about it.

Is this SQL TEMPORARY TABLES thing a new V2 issue - because V2 uses them, and before, '1.7.3' didn't ?

Anyway, all big French hsosters (ovh.fr - amen.fr - 1and1.fr - I use each of them) just work great with V2.
For a mere 25$ a yaer

yes, it seems new to V2 and obviously, if you look through some reports here, it seems, that many problems stem from such restrictions...

i do understand ISPs, that are afraid of big serverloads, since the killing of connections seems to cause problems in the database and if the scipt is written badly, sooner or later the have the max-connections reached. on the other hand, an ISP should be a little bit ahead and make sure his servers can hold such a load...

as mentioned before, i allready paid for a year, and up until now, i was very happy with my host... ohh the struggle moving all my stuff to a new host also makes me shiver...

I am trying a free host atm and emmbed the roster. maybe that works...

Yes, roster 2 uses temporary tables for backup during addon installations. It may be possible to use normal tables rather than temporary ones and deleting them manually afterward. Or just not backup at all, and run the risk of ending up with a broken db if the install sql contains a bug further on.

Or place the option in the hands of the user, possibly?

"If your hosting service supports Temp Tables, and you would like to ensure that your database is not damaged during an addon install, please check this box"

Could that modularity be coded in?

I'd include a check for that function, before it is offered in the menu. and yes, give us the option. pls

What
You're guys are nuts: asking for even more user config buttons ( )

Testing if these tables are accepted is simple.
Just have a dummy be created when handling 'Add On' adding (and Roster Diag printing).

When it works => use it as before.
When it doesn't => switch to an alternative method.

Let this being shown as on on / off field in the Diag section as a flag.

All this to circumvent the situation off seeing a lot of future posts about "Why isn't it working... ?" - with always the same answer "Did you checked the other table handling... ".

There are sql mechanisms to request what the currently connected user can do (SHOW GRANTS FOR `user`;, out of the back of my head). However it outputs the SQL statements that assign those rights, which isn't all that easy to parse a specific permission out of.
mysql 5 has a readable table with those permissions, which is much easier to use. But we need to support 4.1 too...

why parse it, if you can just try making a temporary table and if there is a bad result, turn it off. as tuigii said. at least it sounds simplier. but what do i know... ^^

Ok, I'll get it :

When entering

Code: Select all

SHOW GRANTS FOR `my-database`

(mine is called 'papyteam') I get :

Code: Select all

GRANT CREATE TEMPORARY TABLES ON *.* TO 'papyteam'@'%' IDENTIFIED BY PASSWORD '*2A4386132FFBB0CC9B8828D4507FCFC8E5F9D28F'
GRANT SELECT, LOCK TABLES ON `papyteam-n`.* TO 'papyteam'@'%'
GRANT SELECT, LOCK TABLES ON `papyteam-s`.* TO 'papyteam'@'%'
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE ON `papyteam`.* TO 'papyteam'@'%'

So this is MySQL 5.x only.

No, SHOW GRANTS is mysql 4.1 too. I just think it might be problematic to parse it correctly. Apart from the grant lines you pasted, there are also some shorthands like GRANT ALL that can pop up if they've been used to set the grants.

Trying and checking for an error is ugly.