[peterlaursen]

But CURRENT_USER cannot be used as DEFAULT?

If I try with SQLyog CREATE TABLE/ ALTER TABLE it is enclosed between '' in the SQL.

[peterlaursen]

Let me add that with 5.0 distribution system was changed. The TRIAL cannot be upgraded. You must have a new binary build. You will have a link to the download sent by e-mail.

I don't remember if the download link will display in your browser after your payment has been confirmed.

[peterlaursen]

did you go here:

http://webyog.com/sqlyog/buysqlyog.php

*Buy SQLyog* is in on the very top of the right-hand menu. I cannot see that it can be much easier.

[peterlaursen]

have a look a this

'localtimestamp' can be used exactly as current_timestamp. Also 'on update …'

(howeveer the server (also 5.1.6) converts it to current_timestamp – 3.23 does not support 'localtimestamp' with 'on update' (tried – returned syntax error).

So they should be supported exactly the same way.

I think the MySQL docs http://dev.mysql.com/doc/refman/5.1/en/dat…-functions.html are ambigious. it says:

1) It says that current_timestamp is synonyn of now() and localtimestamp is synonym as now()

2) but these statements:

— CURRENT_TIMESTAMP and CURRENT_TIMESTAMP() are synonyms for NOW().

— The CURRENT_TIMESTAMP(), CURRENT_TIME(), CURRENT_DATE(), and FROM_UNIXTIME() functions return values in the connection's current time zone

contradict I believe!

Oracle behaves like http://www.cs.ncl.ac.uk/teaching/facilitie…unctions64a.htm and undoubtedly that is where MySQL aim at. But seems not to be implemented yet! Do I understand right, u think? Maybe a question for MySQL?

But (maybe) localtimestamp should be implemented in SQLyog exactly like current_timestamp. If the server wants to convert – then let it as long as it lasts!

And UTC_TIMESTAMP ??

I must admit that 'localtimestamp' is the only additional keyword I can find that works as DEFAULT when searching the embedded database ! 🙁

[peterlaursen]

Now ..

It looks like CURRENT_USER is not a keyword that can be used as DEFAULT with a column definition. I thought it was. CURRENT_USER() is a valid function however.

What KEYWORDS else than NULL and CURRENT_TIMESTAMP should be supported by the new SQLyog 'smart DEFAULTs' feature?

[peterlaursen]

I have answered this.

Quote:

If 'lower_case_table_names' is '0' on one server and '1' or '2' on the other sync should be case sensitive as default. However if there is no conflict a popup could display offering to do the sync anyway. And to avoid server errors the name-CASE of the table on the server where it is case sensitive should be use.

replace 'conflict' with 'ambiguity' for clarity.

Now figure:

You sync a LINUX with a `TABLE` and a `table` with a Windows having either. If case-insensivity is chosen in preferences and user not aware, what will happen? Windows will be sync'ed with the one first returned by SHOW TABLES on LINUX. That is a risk!

[peterlaursen]

Quote:

but till now this MACHINE-GUN sound problem has only been reported by you.

I know. the reason I wrote it here was to get some feedback if other users experienced the same. But I believe that when I first reported I was around 20% of users. That is another way to describe it! One user only or 20% ?! 🙂

I believe that I read that the SQLite web claims that TEMPSTORE in MEMORY is safe. Even if SQLyog should crash (and SQLite with it) there is not risk of corruption of the .db files. However if Windows should crash or in case of hardwae or power failure there is a risk. But that applies to DISKSTORE as well! I shall not guess which is most significant!

[peterlaursen]

I still think my proposal is more 'strict'. Server configurations tell you whether CASE is significant.

But I have no issue with this personally! And a setting will be OK too. Now that setting should preferably be displyed by the wizards as a reminder – and maybe even be changable from the wizards.

[peterlaursen]

Quote:

I think we should keep the menu option enabled to allow a user to add a reference to a SQL file to the favorite without

I think so too! Also applies to HTTP-links when implemented!

[peterlaursen]

Quote:

What if a USER actually wants to enter a blank string and not NULL.

he could then enter “`” (backquote). That is implemented allready though not documented

Quote:

For a column having auto_increment value….

that is true. Bull still the idea with auto-increment is taht server should handle it.

Quote:

if somebody specifically wants to insert a NULL value, he will need to write (NULL). 

That is an strange construction in my opinion.  Those paranthesises are absolutely non-standard.  Why not just NULL then?  If user wants to insert (literal) '(NULL)' he will have to write “`(NULL)”.  So you don't avaoid the use of backquote if you should handle all cases (of which most are close to absurdity – agreed!)

Quote:

We plan to keep BLACK cell …

I don't understand

Now tell me:

1) How will you handle CURRENT_USER etc. It should not insert 'CURRENT_USER'

2) I reported a BUG – documented with screenshots. Default was NULL – I did not enter anything in that cell and it inserted '' (empty string). Comments? Now if you say that it displays (NULL) when NULL is DEFAULT how will I be able to tell if it actually is NULL or if it is '(NULL)'

I still think my solution is the correct and logical one. It lets the server do what the server is designed to do. Also the solution most compatible with most sql_modes.

[peterlaursen]

more specific:

an INSERT or UPDATE statement generated from DATA or RESULT panes should skip a column when:

1) type is TIMESTAMP when defined as 'on update CURRENT_TIMESTAMP' (no matter if there is a DEFAULT and what it is and no matter if it is NULL or NOT NULL)

2) column has a DEFAULT (no matter what that default is) and cell is empty

3) cell contains a DEFAULT that is also a supported KEYWORD (CURRENT_USER etc)

4) column is auto-increment

This will let the server do its job as it should! It think that this is all there is to it!

[peterlaursen]

You can do INSERT.. SELECT only provided that the databases are on the same server/host.

You can use SQLyog 'copy (source) table to other host', then do the INSERTS into target and then drop the copy of the source if databases are on different servers. But that of course could take its time with big databases.

With SQLyog Enterprise DATA synchronization you can sync (what includes inserts) between hosts and you can filter rows to sync using the clause. But it only lets you sync complete rows – not individual columns or the rows that have been 'filtered-in'. refer to: http://www.webyog.com/articles/Using_SQLyo…L_Databases.pdf

NB: edited. garbage that I wrote in the first place!

[peterlaursen]

Now …

if you are a daring person you may try 5.1 BETA as well. You can install it in another folder.

Also if you read this http://www.webyog.com/forums/index.php?showtopic=1915 I had a strange experience that display of my national (Danish) characters æøåÆØÅ as well as German, Swedish, Spanish etc characters displayed as cyrillic.

Renaming the SQLyog.ini file and starting SQLyog made the program start building a new SQLyog.ini. And the problem was solved! So I suspect that we have an issue with memory management when SQLyog.ini gets too long or too messy that caused som kind of overflow and damaged my system fonts buffer.

That could be your issue as well. So if you experence that crash again you could try with a fresh SQLyog.ini.

[peterlaursen]

and …

3) an insert-trigger type (transparent to user) should be implemented as well!

[peterlaursen]

Nice idea! 😀

As a one-way STRUCTURE SYNC from ODBC to MySQL I think it can be done!

The other way around is much more problematic!

[Author]

Posts