[peterlaursen]

It is not possible! It is not a restriction with SQLyog, but with MySQL itself. The reason is that the database names exists not only in MySQL tables but as filenames in the filesystem as well. Changing both system tables and filenames is not without problems in case of a server crash in between. You may be left with nothing then! So for security reasons a 'rename DB' is not available.

However, you can copy your database to a new one in different ways. At least:

1) make a backup with SQLyog and change the 'use' SQL-statment in the dump-file to new DB-name before importing.

2) create a new empty database and “copy DB to other host” using SQLyog. Don't be confused – it works with two DBs on the same host as well! When it is done you can drop the old one.

But no matter how you do it involves copying all data, and it will take a lot of time with big DBs. And if you have ONE DB ONLY at a webhost you will need to backup, drop current DB, change 'use'-stmt and import. Be sure to use a 'Bulk Insert' setting that you know works with the server configuration. Probably it is safest NOT to use BULK INSERTS at all! Though that would increment the time for restore.

I think I read in the MySQL that they plan to implement a 'rename DB' (in MySQL 5.1 I believe), but it will still be a create-copy-drop operation (but implemented in one command) – not just a rename operation. And it will still take a lot (the same) amount of time.

[peterlaursen]

You are sure that type is not TEXT ? (not the same as VARCHAR!)

TEXT's are similar to BLOB's except that they have a charset.

What is the SQLyog version you use and the MySQL server version?

How do you conncet?

To me this looks a little strange…

[peterlaursen]

I'm sorry but I don't understand this.

Could you specify where you enter that query?/those queries?

What is the ODBCsource that you import from?

Could you paste in an example? or provide a screen-dump?

And what do you want to accomplish with that can't be accomplished by now?

[peterlaursen]

Quote:

a list of duplicated rows in case of an auto incremented PK row

Dublicated rows simply can't exist if there is a PK. The server prevents this! At least the value of the PK differs for each row!

Please explain!

And BTW: I'll play it back now 😀

auto incremented PK row >>> must be >>> auto incremented PK column

(information for others: Shawn PM'ed me a note about a row/column mismatch in one of my articles!)

[peterlaursen]

now Sergio asks:

Quote:

Tive que reinstalar o software porém perdi a chave de liberação como faço para conseguir uma nova

[peterlaursen]

What I mean is that if you highlight a table i Object Browser, the create statement for the table is there.

Then mark-up any column-name and copy to clipboard with ctrl-c

Then paste it into editor with ctrl-v

[peterlaursen]

You know that you can copy-paste from OBJECTS pane ?

[peterlaursen]

It imports perfect here with attached settings.

Both columns imported to were created as varchar(255)

[peterlaursen]

Quote:

The .xml file does have the extension .sql

The save file path was just too long for the application to handle, not sure why?

I would like to test if it is a bug with sja.exe, or a character buffer limitation on your system (or windows as such). BTW: which windows version are you running?

Can you reconstruct how many characters you had before? 128? 256?

Since exactly two characters were thrown away you must have been very close at the limit. Actually limit + 2!

Could you try a copy statement from commandline like

“Copy myfile.sql yourverylongpathinthexmlfilebeforemyfile.sql

It also could be a possibility that there was an end of string encoding character sequence or just an unprintable character (illegal in filenames) between 's' and 'q'

[peterlaursen]

The graphics refers to this icon-collection:

http://www.iconbase.com/

Maybe he suggest that you should change the icons of the SQLyog program ?

Or maybe he just wants to do that for himself.

[peterlaursen]

Not here. I get exactly “backup.sql” if that is what I request!

What does the

[peterlaursen]

I absolutely am not at home here but MySQL documentation says:

http://dev.mysql.com/doc/mysql/en/miscella…functions.html:

A UUID is a 128-bit number represented by a string of five hexadecimal numbers in aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee format:

.. and that is 36 characters indeed, if you want to store it as a string.

a 128 bit integer is a little higher than 3.4e+38 ( = 34 followed by 37 “0”s if you prefer!) in decimal notation and since range of a BIGINT is only -9223372036854775808 to 9223372036854775807 (far from 3.4+38) I guess you will have to store it as a string!

Another resource:

http://searchwebservices.techtarget.com/sD…i805876,00.html

[peterlaursen]

@Claus

I think this should in our FAQ!

Would you mind explain a little bit further ?

And one ore more screenshot(s) explaining where and what you did would be much appreciated.

Do you know whether this is an issue related to a specific Sybase version or -configuration ?

[peterlaursen]

http://www.webyog.com/faq/29_52_en.html

[peterlaursen]

A little more research.

A BIT type as of 5.03++ simply can't be dispalyed in text – because it is purely binary and has no charset and is not a numerical either! In this respect it is similar to a BLOB (no matter that I know perfectly well that a BLOB is often used for character data. Up to MySQL 4.0 it does not really make much difference either. But from MySQL 4.1++ people should stop doing that and use TEXT instead (just my side-remark). It becomes increasingly important to distinguish between data types that have a charset representation and those that have not!)

Se attached pic. If it is defined as BIT(9) (9 or anything greater than 8) it displays like this in RESULT-pane. If it is defined as BIT(8) (8 or less than 8) it displays as a square (nonprintable ANSI-value).

The solution as far as SQLyog goes is in my opinion to enable the BLOB-viewer for BIT-types – and to implement the request to have an option to display binary content in binary/hex view (and to let it recognize BITs LTE 8 as well !)

Using BIT as a boolean type simply is 'wrong' as of MySQL 5.03++! Or rather a BIT(1) of course can of course be used for that. Actually a BIT(8) can be used as an 'array of 8 booleans'.

But for backward compabitility use TINYINT(1), and for the future and for STANDARD SQL compability use BOOL.

[Author]

Posts