Today when I opened my website I saw question marks instead of texts. Question Marks are showing in japanese and tajik languages. The strange is that inside database it is also ?(Marks).
Does anyone know what is the problem? I have Joomla 1.5 and JoomFish for translating website language. Question marks are shown on all japanese characters. In Tajik language only in some characters are being shown ? marks. My website is navrasta.com
I have had the exact same problem with a JoomFish installation on Joomla 1.5.
From time to time some of the articles would contain just question marks ("?")
Those articles would be lost and I would have to recover them from backups.
What solved the problem for me was to change the database to have my tables use the charset "uft8" and the collation of "uft8_general_ci". Previously I had "latin1_general_ci"
Please backup your database before you attempt to do this.
You should change the charset and collation for at least these tables:
"jos_content" - your articles are stored here in the default language
"jos_jf_content" - your translation are stored here.
(of course you need to replace 'jos_' with your actual table prefix)
Good luck and always do backups before altering the database!
Related
I have a requirement where 300 columns had to be processed. I am trying to achieve this using IG automatic row processing (DML). When writing the code in the editor I get a error stating 'Value too long by 2015 characters'.
I suppose this is an Oracle Apex limitation. Can someone please share their views on this?
When writing the code in the editor ...
I'd say that your problem isn't related to number of columns, but a large query which can't fit into "SQL Query" item of the Page Designer.
Which Apex version do you use? I can't tell for sure (as I don't know it), but my impression is that Apex up to version 4.2 had that item limited to VARCHAR2(4000) so - if your query is larger than that, it won't fit (such as in your case - query you wrote is 2015 characters longer than the maximum size the item allows). In 5.x version, you can put a whole lot of query into the item (as if it was modified to a CLOB).
Now, as you use Interactive Grid and it appeared in 5.x version, huh ... maybe what I wrote above isn't entirely true. Unfortunately, you can't switch to a query whose source is a function that returns query (such as in Classic Reports), as you could write a (stored) function and simply call it from Apex.
As you said that you used automatic row processing, did you put too much code somewhere in there?
On the other hand, I Googled a little bit, looking for limit of column numbers in the IG - couldn't find anything official, but someone complained (here, on StackOveflow) that they tried to create an IG with over 100 columns, and it didn't work.
So, yes - maybe you hit the limit, but I can't confirm it. Hopefully, someone who knows Apex better will be able to assist. Alternatively, consider asking the same question on OTN forums, as people who designed Apex answer questions there.
When I change the encoding in my browser(s), the controls in the cart change accordingly when I have extended chars.
However, it is not consistent and looks very amateurish. See the attached comparison image.
How do I fix this in Magento 1.4.0.1? Or, is it a browser issue, and if so, how do I fix it?
How did you create your MySQL server? When you didn't set correct collation while creating a database, you can always face of troubles. Try following :
mysql > CREATE DATABASE sample DEFAULT CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI;
UT8_UNICODE_CI has many character sets.
I'm having trouble with the number formatting in Apex 3.2.1. NLS_TERRITORY is set to GERMANY, NLS_LANGUAGE to GERMAN. However, the default number formatting is wrong and I would like to fix/change it. I'm wondering why there is an application date format setting but no application number format setting. That would have been really helpful right now. So my question is: how can I set a new number format which will be applied everywhere in my application? Is it possible? If not, what would be the least painful way to to apply the new format mask. I'm mainly concerned with interactive reports. Additionally, if it were possible to change the default format mask for the territory in some configuration file, that would also be an option. Thanks for your input in advance.
Edit:
My problem with the default format is that numbers like 0.34 are being displayed as ",34", but the correct output would be "0,34".
Okay, purely the display then. I don't think there is an easy way to do this for all your fields, but specifying a format mask on those fields, by using for example FM999G999G990D000.
That would be annoying for a lot of fields across the application though, i agree. It is even more annoying when only by specifying a format mask, items are recognised as being number fields. Maybe making a plugin, which is identical to a number field, but with a default format mask may do the trick.
Or query the apex views to find items, then update them (though you will need access to the 'internal' tables of apex, the wwv_* things).
select application_name, page_id, page_name, item_name, display_as, display_as_code, format_mask from apex_application_page_items where page_id = 6
Which you could then transform into an update...
I've nothing else to offer, so far i've always specified the format mask during development...
I have this application that uses natural primary keys. The database uses the WE8ISO8859P15 character set. So in my table City whe have primary keys like 'MEDELLÍN' and 'MÜNCHEN'. I have a hunch we are going to have a lot of trouble with this.
The problems I see
Interfacing this data to databases with another character set. I don't want character set conversion on my primary key
Dumping the data to files and processing these files we always have to very aware of the special characters and the client settings
Should we allow diacritics in the PK? Please feel free to give your opinion.
Trying to ignore diacritics is just delaying the inevitable. Yes, you could save some issues in Eastern Europe. But you still can't deal with Greek city names. You'd need Unicode, and then there's no point anymore in misspelling Munchen/Muenchen; it's München.
That said, the entire notion that there's a single name for a city already breaks in Brussel aka Bruxelles, and that's Western Europe. So, they're fundamentally unsuitable for primary keys, no matter how you'd spell them.
Why not? You DB model is broken beyond repair already, so why not introduce another source of problems? ;)
More seriously, databases are getting better at supporting Unicode, so there is no problem with storing natural text (with all it's oddities). Your issue is "primary key". There are several ways in which the same text can be encoded (for example, you can have accented characters or diacritics with plain characters). This means you can get two different keys for the same text.
There are a lot of wrong reasons to use business keys as PK and no good ones. Don't do it. Bite the bullet and fix it. Fix it now. It will cost you less (even if it costs a lot) than not fixing it.
Like you, I feel it would be really looking for problems to allow them.
In addition to the problems you mention, it could be:
Imagine switching to another database vendor ...
I don't know if introducing a surrogate primary key is an option for you, but that could be the correct timing to do so ;-) ...
If not, you could duplicate the column :
the pk column would not be case sensitive, not have special characters and so on ...
an additional column would preserve what was entered by the user, to show it nicely in some UI...
Yes you will have problems with those characters. Leaving ASCII always causes problems. But when you do business not only in britain and the US, you don't have a choice.
I don't see special character set related problems for the Primary Key. If you export, import, interface or migrate you'll have to take these characters into account no matter if they are part of your PK or not.
But they do emphasize the problem of a natural key as primary key. It seems to be extremely likely that someone will write e.g. Muenchen just to later change it to München, which of course will cause the well known problem of updates on PK.
Whether your attribute is (part of) a key or not has nothing to do with the issue.
You have issues of character set conversion with ANY data traffic to/from this attribute anyway, regardless of whether it's a key or not.
Yes, in order to encode "correctly", and have the best possible guarantee that your data will never get corrupted because of character set conversion issues, you need the Unicode character set and one of its encodings.
I do have some serious doubts about the table itself, incidentally. What do you do with Heidelberg, Germany and Heidelberg, South Africa ? Oxford, UK and Oxford, US, where there's even hardly a state without one ?
What kind of information depends on that key ? If there is none at all, then your table is more of a "variable type" than it is a "genuine table". In that case, you might just as well forget the table and make your cityname attributes just plain String.
If you are really required to produce some "canonical spellings" for citynames when exporting data from the database, then I'd advise to try and set up a "phonetic search table" in which "commonly used spellings" are linked to the "canonical spelling" you are required to produce. Expect a serious effort in getting such tables populated, however.
In that case, then in addition to the already mentioned München/Muenchen and Western/Greek alphabet issues, don't forget about the Liège/Luik/Lüttich (München/Munich) kind of issues.
Things change their names, or have their names changed for them. Cities, Universities, Parks, People .. all unsuitable as Primary Keys. Unique Key, maybe? Or part of a Unique Key?
I am using NHibernate to query an Oracle 8i database. The problem is that all the strings in the returned objects are postfixed with special characters. For e.g.
CUSTOMER,ONE�������
The nhibernate field type is AnsiString and the Oracle datatype is CHAR(20) and the Character set is CHAR_CS. I am totally new with Oracle so i don't have a clue whats going on :(
CHAR(20) means the field is padded as necessary to be exactly 20 characters long. The padding character is a blank.
There must be a problem somewhere in your character set settings if padding characters appear as question marks. You may find more insight on your problem here.
What you need here is to trim the returned strings, or better yet move to VARCHAR2(20).
I couldn't find a proper solution for this issue but changing the nhibernate driver from 'OracleClientDriver' to 'OleDbDriver' solved this issue. Still if anyone knows how to tackle this issue properly please let me know as I don't like using the OldDbDriver for accessing Oracle because of possible compatibility issues.