[crivera]

Quote:

QUOTE

Apache 2.0.53, IIS 6.0

at the same time ?? and maybe even php installed as a module with both of them ?

I might have asked about this before, but direct/tunnelled connection ??

Actually I run IIS on port 80 and Apache on port 8080 which allows me to test my PHP scripts on either type of server.

Anyways, I think that this issue is not going anywhere. I am pretty sure that nothing is wrong with my system nor my database setup.

I am also pretty sure that any reserved word in the query statement is case insensitive however for some obscure reason your software does not think so.

The only thing I can add is that this bug only occurs during some complex SQL queries that I have written (i.e. joins, unions, and subqueries) when all the reserved words in the query are in UPPERCASE. It's not a big deal — I just change one word in my query and I ready to look at the results. 😀

BTW, your software is really great and a significant improvement from what I have been using — phpMyAdmin. Keep up the good work.

[crivera]

Ok, I ran the queries from the MySQL client tool (**sigh**) and saved the results to text files. Ran a file compare and the results were identical.

FYI: I am running XP Pro Sp2, MySQL 4.1.11, Apache 2.0.53, IIS 6.0

I will upgrade to MySQL 4.1.12 and keep you posted.

[crivera]

image 4 of 4

[crivera]

Image 3 of 4

[crivera]

Image 2 of 4

[crivera]

Tried the new version 4.07 and got the same results.

I understand that the cell content may contain non-displayable characters. However, I do not think that this should be the case for the column names.

Here are the 4 queries from the screenshots. Note: All 4 queries are the same and should produce the same results. Query #2: changed “SELECT” to “select”. Query #4: Changed “FROM” to “from”.

SELECT * FROM hhdesigns_pages LEFT JOIN hhdesigns__templates ON hhdesigns_pages.Template=hhdesigns__templates.Template LEFT JOIN hhdesigns__templatescontent ON hhdesigns__templates.TemplateContent=hhdesigns__templatescontent.TemplateContent WHERE hhdesigns_pages.Page=1001 ORDER BY hhdesigns__templates.TemplateIndex ASC;

select * FROM hhdesigns_pages LEFT JOIN hhdesigns__templates ON hhdesigns_pages.Template=hhdesigns__templates.Template LEFT JOIN hhdesigns__templatescontent ON hhdesigns__templates.TemplateContent=hhdesigns__templatescontent.TemplateContent WHERE hhdesigns_pages.Page=1001 ORDER BY hhdesigns__templates.TemplateIndex ASC;

SELECT * FROM hhdesigns_pages LEFT JOIN hhdesigns__templates ON hhdesigns_pages.Template=hhdesigns__templates.Template LEFT JOIN hhdesigns__templatescontent ON hhdesigns__templates.TemplateContent=hhdesigns__templatescontent.TemplateContent WHERE hhdesigns_pages.Page=1001 ORDER BY hhdesigns__templates.TemplateIndex ASC;

SELECT * from hhdesigns_pages LEFT JOIN hhdesigns__templates ON hhdesigns_pages.Template=hhdesigns__templates.Template LEFT JOIN hhdesigns__templatescontent ON hhdesigns__templates.TemplateContent=hhdesigns__templatescontent.TemplateContent WHERE hhdesigns_pages.Page=1001 ORDER BY hhdesigns__templates.TemplateIndex ASC;

As I mentioned in my earlier post, I could change my SQL syntax to lowercase and get the correct column names.

Image 1 of 4

[crivera]

I will try the new version and see if the problem is fixed.

Quote:

2) I also can see that the string-types are displayed by your SQLyog as BLOB. Now, SQLyog display does not distinguish between BLOB and TEXT types, so I guess that they are defined as TEXTs (??). But do you need so many characters as a TEXT can hold ? Won't a varchar(255) do ? And BTW char/varchars are more effective with MySQL than are TEXTs.

Yes, I could have used varchar(255) however from the MySQL manual, MySQL would have converted those fields to TEXT anyways.

Quote:

[NATIONAL] VARCHAR(M) [BINARY]

A variable-length string. M represents the maximum column length. The range of M is 0 to 255 characters (1 to 255 prior to MySQL 4.0.2). Note: Trailing spaces are removed when VARCHAR values are stored, which differs from the standard SQL specification. From MySQL 4.1.0 on, a VARCHAR column with a length specification greater than 255 is converted to the smallest TEXT type that can hold values of the given length. For example, VARCHAR(500) is converted to TEXT, and VARCHAR(200000) is converted to MEDIUMTEXT. This is a compatibility feature. However, this conversion affects trailing-space removal. VARCHAR is shorthand for CHARACTER VARYING. As of MySQL 4.1.2, the BINARY attribute is shorthand for specifying the binary collation of the column character set. Before 4.1.2, BINARY attribute causes the column to be treated as a binary string. In either case, sorting and comparisons become case sensitive.

[crivera]

Just emailed you the information you requested.

[crivera]

Note that both queries are the same from Image 1 & 2. However, the “RESULT” is different because of the column header information.

The only difference is the SELECT statement:

UPPER CASE in the 1st query

LOWER CASE in the 2nd query.

I could change all my SQL queries to lower case … 😉

[crivera]

2 of 2 screenshots

Lemme know if you need additional info.

[crivera]

1 of 2 screenshots

[crivera]

thanks for your reply.

Quote:

This I don't understand:

When I am trying to modify table data, I constantly have to swith between the Table Data & Result tab to determine which row to edit

You can edit from the RESULT-tab – you just will have to select the table to edit from the drop-down-box showing “Read Only” (this is security feature and very useful with multitable queries/JOINs)

To view the data behind the blob object, I had to select the “Show Result In Text” option (Ctrl-L)…

Quote:

did you check the 4.07 beta/RC-version ? It now displays the beginning of the string/data (using the defined character set for TEXT and the default character-set for non-TEXT, I believe)

A binary/hex view of data with the BLOB-viewer I know is on the TODO-list (and can't be far away).

Making the BLOB-viewer resizable is too.

I will check it out.

[Author]

Posts