[peterlaursen]

Quote:

Now I am puzzled…

This ticket system is new to all of us. I apologize if I did something wrong

Quote:

The one I was told to use (and have used for other applications ?!?!) didn't work with SQLyog. But changing it to the smtp server of on of the leading ISP's in Denmark solved the problem.

I think, because the first one is not a real server – and only relaying to and from SMTP at Cybercity (error messages told that) – you might as well go directly to the REAL server. I cannot tell why the relay server does not work wiht SJA, but it must reply in some non-standard way. I think it might be a program that is part of some corporate subscription/hosting plan. If we shall do deeper into it we need more information about this program and its configuration.

edit: I now read your most recent posts in the ticket and it is quite strange that you cannot use the same HOST that I can. Still info about how this 'relay.zz.yy' 'server' is working will be needed to explain things!

[peterlaursen]

Open SSH FAQ at http://www.openssh.com/faq.html#2.12

Quote:

This is usually the result of a packet filter or NAT device timing out your TCP connection due to inactivity. You can enable ClientAliveInterval in the server's sshd_config, or enable ServerAliveInterval in the client's ssh_config (the latter is available in OpenSSH 3.8 and newer).

Enabling either option and setting the interval for less than the time it takes to time out your session will ensure that the connection is kept “fresh” in the device's connection table.

I don't think the latter option is available, but do you have access to the server config?

[peterlaursen]

Please read: http://www.webyog.com/faq/26_49_en.html.

So I just think you will need to change

Code:

DELIMITER $$

to

Code:

DELIMITER $$;

We discussed recently here http://www.webyog.com/forums/index.php?showtopic=1990

It would be nice if SQLyog supported both forms, but the DELIMITER statement is NOT part of the (my)SQL language, and any client can implement this as it likes.

An actually the concluding delimiter statement in your script follows Syntax that SQLyog supports – and not MySQL command-line syntax!!

[peterlaursen]

And I also think you have the solution there!

[peterlaursen]

@Allan

there is an additional question for you in the ticket system!

[peterlaursen]

I don't understand!

Where did you create that support ticket? Not in webyog support system I believe.

What reply to what question ?

[peterlaursen]

I tested with 5.02 as well. Still no problem here.

I think you must give more information about the mail server program and its configuration.

Obviously it returns something that SQLyog interprets as a request for authentication.

Could you create a temporary account and create a ticket with details here:

http://www.webyog.com/support/ttx.cgi

I think then, that they can log the server response details from the office in Bangalore.

[peterlaursen]

Strange …

I tested this with 5.1 BETA2.

I did not check ' …requires autentication'. And backup was made and the mail sent and received successfully. Jobfile sendreport section looks like

Code:

peter
[email protected]
[email protected]
[email protected]
post.cybercity.dk 25 test

You are SURE that the mail server does not want authentication?

Try check it and give in UID and PW for the mail account that you use with ?

[peterlaursen]

Also note that it does not becomes SQUARES when displayed in the GRIDs (as non-printable characters would display). It becomes chr(63) = '?' and is consequently displayed and exported as such.

@ritesh: I doubt that you coded taht yourself that way?! The VC++ library code that does this?

[peterlaursen]

On my system (Dansih localized Windows) HTML and CSV also produces '?'s. this is what I get from CSV export of sizes table

Code:

“01”;”???????”
“02”;”???????”
“03”;”???????”
“04”;”??????? (????)”
“05”;”?????????”
“06”;”????????”
“07”;”??????????”
“08”;”?????????”
“09”;”?????????”
“10”;”????????????”

Also it displays like that if I choose a font in Notepad that supports cyrillic (such as Arial). In a hex editor all cyrillic characters have become '3F' (decimal 63) – that is ASCII/ANSI/UTF8 for '?' That must mean that the information is not there and was lost!

But @Chrono: do data display as cyrillic in DATA and RESULT panes on your system?

I can add that all types of export export my national characters (æøåÆØÅ) correctly. I have an issue with HTTP-write however, but probably quite another issue!

[peterlaursen]

Also the comma before Engine is not in accordance with http://dev.mysql.com/doc/refman/5.0/en/alter-table.html

The comma should be inserted BEFORE #2, #3 etc alter_specification not AFTER #1. And it does not work with MySQL 5.1 this way! I think we did fix a similar comma-issue before?

With MySQL 5.1:

alter table t1 Engine=InnoDB;

>> works

alter table t1, Engine=InnoDB;

>> Error Code : 1064

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' Engine=InnoDB' at line 1

[peterlaursen]

Also ..

I believe I read here http://forums.mysql.com/read.php?108,32285,74300#msg-74300 that Mike Zinner wrote tha MQB uses unicode internally. But it seems like he has edited!

[peterlaursen]

I compared 'MySQL Administrator' and 'MySQL Query Browser'

1) a backup with MA preserves cyrillic charset information. When opened in Notepad table 'sizes' looks like

Quote:

INSERT INTO `sizes` (`size_id`,`size`) VALUES

(01,'Мужские'),

(02,'Женские'),

(03,'Унисекс'),

(04,'Женские (мини)'),

(05,'Карманные'),

(06,'Каминные'),

(07,'Настольные'),

(08,'Настенные'),

(09,'Напольные'),

(10,'Метеоприборы');

2) An export as HTML/CSV with MQB also preserves charset information

3) No export format from SQLyog preserves the charset info. Looks like it is irreversible converted/destroyed when it is loaded into SQLyog.

4) I a font is selected that supports cyrillic (here ARIAL is used) MQB even displays cyrillic display.

5) I think there is a bug with SQLyog 5.1 beta2: It is not possible to change the font.

6) And the fonts' control is somewhat outdated: you must choose a 'script' (a mapping/encoding) That probably is how the library does but it should be possible automatically choose a 'script' that corresponds to the COLUMN default setting. You need not in MQB – it finds out itself which 'script' to use. But I don't think this is related to the export problem.

[peterlaursen]

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!

[peterlaursen]

Quote:

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?

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..

[Author]

Posts