[kuroi]

Alas Peter is right. We're web developers who turned down a juicy piece of work a while back because it would have involved working on Windows servers, an environment with which we're unfamiliar, and we recognised that the hassle and scope for screwing up outweighed the possible benefits.

So, SqlYog does work under WINE (which is how we use it). It's not so pretty and it bugs us sometimes, but it remains effective. Much as I'd prefer to use it natively, and we'd certainly pay for that if it were available, but more important is that it just continues to work and evolve as a key component in our design and development tool box, and that we don't hang a heavy development and maintenance weight around Peter's neck.

[kuroi]

OK. Ignore this.

Having moved on to other stuff, I started to notice other apps doing mildly odd things and concluded that something, somewhere deep in Vista was not everything it should be. A quick reboot and everything was OK again. I've obviously been spending too much time on my Mac and Linux machines and had forgotten that Windows needs a reboot from time-to-time.

Thanks for your help Peter, apologies to have taken up your time.

[kuroi]

Not a lot of joy alas.

Deleted the tags folder and reinstalled. No joy. Tried again with McAfee turned off. No joy.

Found the keywords.db and deleted it. Tried again no joy.

Found an older version of sqlYog Enterprise. Uninstalled that and the already installed version and reinstalled from scratch. Now get a message telling me that Keywords.db is not found or corrupted and asking that I reinstall. It's there and I've tried reinstalling several times but always come back to the same message. 🙁

[kuroi]

1. Problem went away when autocomplete was turned off (though it's rather nice, so I'd like to be able to turn it back on!).

2. Upgraded from 8.17.

3. Never heard of NOD. Sounds like I should aim to keen it that way.

Will try your suggestions and let you know how it goes.

[kuroi]

Thanks Peter. A good idea, but unfortunately didn't work. I suspect that I'm still the wrong side of an HTTP 301 redirect which is re-writing the header received by the tunnelling file (if that's nonsense, feel free to say so!).

However, I have gotten around the problem by gaining access to the client's phpMyAdmin and creating a remote MySQL user, so I'm good for the time being. Many thanks for your suggestions.

[kuroi]

Sorry Peter, I should have said. I've already tried all four header types with Base64 encoding enabled and disabled.

[kuroi]

peterlaursen wrote on Dec 14 2007, 01:30 PM:

Please try copying the .bak.ini to that location and rename to .ini

The manual copy worked fine Peter. And your hypothesis that the 613 update may have fixed the problem that caused it to go funny originally is looking well-supported by how well it's working now (I've tried and I can't break it again!).

Many thanks for your help.

[kuroi]

Ritesh wrote on Dec 27 2005, 12:06 PM:

Just take a backup of SQLyog.ini and restore it after re-insallation.

I know that this is going to be a really daft question … but where is the SQLyog.ini file?

A bit of background. Yesterday my SQLyog 612 stopped recognising my connections. I tried upgrading and am now running 614. My C:Program FilesSQLyog Enterprise folder has a sqlyog.bak.ini file which appears to contain all my configuration settings. But a full search of all my hard disks returns a null result for sqlyog.ini. I can rename the bak file to be this, but as soon as I restart SQLyog, it's named back to sqlyog.bak.ini and ignored.

[Author]

Posts