[peterlaursen]

You are welcome to ask such question in our Forums. Hopefully some of our users will be bale to help you (I cannot because my knowledge about RealBasic == 'black hole' !!).

However SQLyog ENTERPRISE has both SSL and SLL options.

But you may tell how RealBasic connects to MySQL. Is there a 'wrapper class' for the C-API? Do you use ODBC? or how do you connect ??

[peterlaursen]

I told that also I think we should add the information that SHOW CREATE DATABASE exposes about the database to the OBJECTS information. For 5.0.x that is 'default charset' only but maybe that is even more for 5.1, 5.2 and 6.0. Please give us a few hours to research and discuss this on Monday!

And yes .. when some DBA is upgrading MySQL without running the appropriate update scripts/programs we get accused that our (CLIENT) program malfunctions, but it really is the server that does not return the expected information or does not give access because privilege tables were not updated as they should 🙁

I know nothing about DirectAdmin – only YaST (SuSE) and up2date (RHEL)

[peterlaursen]

1)

“I don't have a my.cnf”. Sounds strange to me! But I shall not totally exclude that you are right that some builds have compiled-in defaults and don't need it. Is it a build distributed by MySQL AB or one shipped with a Linux distro? On Linux the my.cnf file would normally be in /etc/ folder.

However I would create a my.cnf if there is none! There MUST be some default settings you want to override (like 'max_allowed_package' for instance)

2)

“So why can't SQLyog show me this database information directly”.

We populate the OBJECTs tab with information for a database using the query

SHOW TABLE STATUS FROM … (HISTORY tab will tell you what queries SQLyog sends).

We will discuss adding information returned by SHOW CREATE DATABASE to OBJECTS tab. I think you are right we should. Basically this OBJECT TAB design goes back to server versions 3.23 and 4.0. Those versions do not support SHOW CREATE DATABASE at all (try and you'll get 1064 syntax error!). But we can differentiate that, of course. We do SELECT VERSION() after connection, so we will know when to send SHOW CREATE DATABASE!

[peterlaursen]

Your are probably not more silly than average 🙂

We do not support SPATIAL datatypes from the GUI (but you can type and execute anything from the SQL editor of course). It would be no big deal to add those types, but we also would then need to display the content of those data a meaningful way – and that is a bigger issue.

There is no plans to add it for those versions (up to 6.2) where features have 'roughly' been defined.

Basically they should be displayed geometrically! And I doubt the demand/effort ratio is high! But of course there are simpler solutions too. What would be a reasonable but still simple implementation for you?

[peterlaursen]

The 'upper level' of a database is the server! CREATE DATABASE creates that database with the server default as specified in the server configuration file (my.ini/my.cnf) unles you specify differently like CREATE DATABASE .. CHARSET.. . Collation default for every charset is defined here: http://dev.mysql.com/doc/refman/5.0/en/charset-charsets.html

The also applies when importing a dump: if the CREATE statements in the dumps contain CHARSET specifications they will be used, if not defaults will be used.

Whether a dump contains charset/collation specifications for tables or not depends on the program generating that dump. But most programs will simply fetch and use the returns of “SHOW CREATE …” with the addition that version dependent conditional comments (/*!… */) may be used to conditionally comment out features not supported on lower server versions.

[peterlaursen]

There is no intentional change between the two versions in this respect. Only reconnection in Structure Sync in know to be broken in 6.0 to 6.05 (fixed in 6.06).

However we did rebuild the PLINK in 6.0 (technically it is plink.exe and not sqlyog.exe that loses connection).

It will take a little time to research this. I will PM you a download link to version 5.32 ENTERPRISE with registration details. Please install this one (to another folder) open a connection with it and let be open overnight and report how this one behaves.

[peterlaursen]

1) Display of charset/collation information:

If no charset/collation is shown in OBJECCTS it is becuase it is the same a the default for the 'upper-level' object. This is how MySQL reports it.

2) Definign charset/collations:

*************************

Option to define charset/collations defaults different from 'upper-level' defaults is planned for version 6.1 (and the coding of this feature is completed allredy, I think we can release beta1 next week or beginning of the week after that)

With versions <6.1 you will have to execute SQL like

CREATE DATABASE CHARSET .. [COLLATE …];

ALTER TABLE … CHARSET .. [COLLATE …];

etc. (there might be slight variations depending of server version)

Note that existing columns will not change – they will have to be changed one-by-one.

Did I overlook something in your post?

[peterlaursen]

Thanks for your report.

Verified as described.

It is too late to fix in 6.06 tree. Fix is planned for 6.1.

[peterlaursen]

I am not sure I understand '.. script create statements for tables'.

You can of course enter SQL yourself in the editor (instead of using the GUI functionalities), but I rather think you would use a script using 'symbolics' or 'placeholders' for the real table and column names – and possibly even use conditional statements and loops/repetetive statements. Do I understand correct?

There is no scripting engine/interpreter or whatever of the kind in SQLyog.

Do you have any idea of what kind of script language would be appropriate?

[peterlaursen]

1) Did you notice that if the .csv contains one or more header lines with column names and similar information, there is an option to skip 'n' number of lines in the import dialogue?

2) With SQLyog (Enterprise) Migration Tool you can import using the Microsoft text-ODBC-driver (skips with Windows). This one will create the column names and types for you (but of course you will sometimes have to adjust it!)

[peterlaursen]

Quote:

… for example

*Queries larger than 4 KB will not be shown i HISTORY. This is by design (to save memory).

*To add batch jobs to HISTORY you must select the option in 'preferences'

Any other examples?

[peterlaursen]

This is a SQLyog question, not a MONyog question. I am moving this topic!

Please post in the correct category!

This is a known issue. It is fixed in the development tree. You can verify with 6.06 beta2.

[peterlaursen]

We have not been able to reproduce it. However I also think we need more exact information.

We simply need a schema populated with data that crashes for you. A DUMP actually (why give us 20 minutes of typing work if we can import a DUMP in 5 seconds?)

You can fake some data and/or create a ticket if you do not want to expose things in public. But this crash must be happening with this schema and data. Error may be data specific and a single character may make the difference!

Also I still request that you try version 6.x ENTERPRISE TRIAL.

Basically you should understand that we do in principle not support this version any more.

At least we will have to ask for an exact and reproducable test case to work with, if we shall work with it.

[peterlaursen]

Yes, SQLyog does

LOAD LOCAL DATA INFILE ….

http://webyog.com/faq/content/28/73/en/i-h…ighlight=infile

[peterlaursen]

yes, I know it is you! 🙂

anything else you want to tell or was that it?

[Author]

Posts