I have downloaded and installed 5.1 beta 2.
After a while I saw that it is "building tag files" for variuos database tables.

Suddenly following message appeared:

"Buffer overrun detected!

Program: .......\SQLyogEnt.exe

A buffer overrun has been detected detected ...
.... must now be terminated."

It must be happened at the very end of the tag building as SQLyog status was "Building tag files completed" when this message appeared.

@vygi

Do you have a lot of databases with a lot of tables with a lot of columns in that connection?

Do you find the .tag file for the connection in \TAGS directory and does it look valid? You can open it with SQLite Query Browser fron here: http://sqlitebrowser.sourceforge.net/

Also now that the tag file has been built can you open it next time you start SQLyog without a crash?

Could you try selecting only a single small database with a connction and open that connection?

SQLite has an option to send a PRAGMA statement allokating a memory buffer for its use. Maybe SQLyog should test for the size of memory buffer that it needs and send that PRAGMA statement.



And how big is that TAG-file?


and @ritesh - actually I have a question too. See the screenshot of my TAGS-folder. There are quite a lot of ZERO-size .db files with cryptical names. What are they? I think it is new with BETA2 - I don't remember this with BETA1.

BTW ...

I moved to the category *BETA discussions*

Continuation:

after this crash SQLyog refuses to start!

It just shows connection dialog and quickly disappears when I try to connect to an already known ("indexed") server.

Then I have managed to connect to two new servers without built tag files.
SQLyog has finished tag building on one of them and can connect to it now.
There is a problem with the 2nd server though: it has crashed (without any messages) during tag file building or right after it and can't connect to it.

So I had four connections to four different servers and only one works.
SQLyog disappears very quickly as soon as I try to connect to the remaining three.

Then I have deleted a .db file from the Tags folder... and - good news - was able to connect to all servers
but - bad news - only as long as tag file building was in process. After them, SQLyog was gone again.

Finally I have connected to a "good" server (which does not crash SQLyog) and switched off "Always Rebuild Tag Files on Startup" option. Now SQLyog sinally starts without any problems.

Vygi

P.S. yes I do have LOTS of tables and fields, and I will take a look at the file soon.

Well ... I cannot tell if this buffer is the internal SQLite buffer or if it is some other buffer that SQLyog uses to cache the DB information. Most likely the latter - but just a guess!

> Do you have a lot of databases with a lot of tables with a lot of columns in that connection?

yes: 5..10 databases, up to 50..80 tables in a DB, up to 50..80 fields in a table.

> Do you find the .tag file for the connection in \TAGS directory and does it look valid?
> You can open it with SQLite Query Browser

yes it seems to be valid.
"objects" has 8519 rows BTW and message_queue + sqlite_sequence are empty.

> Also now that the tag file has been built can you open it next time you start SQLyog without a crash?

only if I switch off tag file rebuilding.
Otherwise it crashes if I select a "rich" connection (server with lots of objects).

> Could you try selecting only a single small database with a connction and open that connection?

yes it works.

> And how big is that TAG-file?

this is a .DB file, not .tag. The size is 1,089,536 bytes = 1,064 KB

> and @ritesh - actually I have a question too. See the screenshot of my TAGS-folder.
> There are quite a lot of ZERO-size .db files with cryptical names. What are they?
> I think it is new with BETA2 - I don't remember this with BETA1.

I have only one single .db file with a long cryptical name.

this is stuff for Ritesh to study! But undoubtedly the is an issue with such amount of data to be cached by SQLyog after rebuild. If SQLite Browser opens the file, the file probably is OK ifself.

Two questions more:
1) does autocomplete work OK with that big .db-file? (if you start without rebuild?)
2) what happens if you start rebuild manually (from 'powertools' ?)

> 1) does autocomplete work OK with that big .db-file? (if you start without rebuild?)

yes it works... somehow... but is quite slow and sometimes I can hardly type so I prefer to switch it off

2) what happens if you start rebuild manually (from 'powertools' ?)

It crashes (disappears) immediately

You won't have to disable autocomplete completely. Only disable tooltips and you can still use TAB, CTRL+SPACE and CTRL+ENTER.
did you read http://www.webyog.com/forums/index.php?sho...st=0&#entry9079

But as I wrote before here .. maybe some of us (including me) should change our habbits a little to get the full advantage of autocomplete. Instead of having one of connection with a lot of database, we could have more connections!

Yes thanks it works that way.
Nevertheless, I am unable to rebuild the tag file so autocompletion may become incorrect one day.

Note that I've got "Buffer Overrun" message only once, just the very 1st time, and did not see it since them. Now SQLyog just disappears quickly without any messages.

This is a known bug which came to our notice only yesterday.

We have fixed it in BETA 3. Expect BETA 3 by tomorrow evening Indian time.

But if you delete/rename the .db file, you probably will be able to rebuild it - from startup or from powertools menu?

Also any change that SQLyog does to your MySQL database that relects the SQLite database (such as adding/renaming a table) will be saved by SQLyog. Only if ANOTHER CLIENT has modified the database you'll have to rebuild!

Can you verify that? Add a small table, close SQLyog, restart SQLyog and the table just add should be available with TAB key. Or maybe changing the .db-file from inside SQLyog cases some error too when it is that big?

But of course this is a bug of some kind. Program should not just disappear! I wonder if it is the CHECKSUMs introduced with BETA2 that runs over! CHECKSUMs were introduced to make 'rebuild tags' faster, when there was a partically complete and correct .db-file allready! I don't know which variable type is used for storing the CHECKSUM and what limitations it has!

But no program should not crash like this.

1MB .db file with 8,519 rows table is big?
In this case, word "Enterprise" should be removed from the product name as SQLyog is not enterprise-ready!
Right now my biggest database server has 14 databases, biggest database has 145 tables, widest table has 112 columns, longest table has almost 151 mio rows, largest MyISAM data file is 45 GB, total size of all data and index files on this server is more than 186 GB

The amount of data (# of rows, file sizes) is irrelevant. It is only the number of database objects that matters.

Of course this should be fixed. But my point is that you don't need to specify all databases with one connection. Actually it is a good security procedure only to specify those that you need with each connection.

Did you try if SQLyog could edit the .db-file at runtime on that server by adding or renaming a table?

Starting from BETA 2, we have changed the .db name from connectionname.db to a filename which is a checksum of the connection name + the connection details. This allows one to have any character in the connection name, multiple connections with the same name and couple of other usability issues.

.db with 0 size is strange. I am not able to reproduce it. Can you just delete the tags folder and connect/reinstall again?



All the above crashes/crash on startup is due to a memory overflow bug which has been already fixed in BETA 3. Now no more crashes.



This was just a bug and 5.1 is still in BETA. Starting with BETA 3, you can have a DB with 'n' number of tables with 'n' number of columns in each table.

Is it right when I have tried 4 different connections but there is only one .db file in the Tags directory?



OK OK OK... I was just kidding...
SQLyog is great (and will be quite ideal when proper export to EXCEL will be implemented).

Well, I think I found out!. If you disable 'rebuild at startup' than a ZERO-size .db file is created when you open a connection that was never opened before. I just renamed my TAGS folder to TAGS-bak and opened a connection and it happened like this - TAGS folder was created and a ZERO-size file created too..

thinking about it ...

I think I understand those 'usability issues'. However I would like the meaning of the names of the .db-files to be human readable somehow. Was it for instance possible to CONCAT the connection name to it so that it would read 'mycon_4282c398ec9d05f8c3ebc7fd25d194ca.db' and not only '4282c398ec9d05f8c3ebc7fd25d194ca.db' ?

Should also not the .db file be deleted (could be optional) when a connection is deleted from 'Connections manager' ?

The TAGS folder could easily be filled with unused files. And with the names they have as of now, you can't tell which ones to delete manually!