I am running a query that populates a TComboBox to let users filter results displayed in a ListView. One of the query results has an E with an accute accent character. The word is CIGRÉ. It shows up in my ComboBox as CIGR..., as shown below.
I have been scrubbing the data to replace the É with an E. Is there a way to modify the query so it retains the original É?
Below is my query code, it returns unique committee names from a big list of meetings (mtgs).
Form1->FDConnection1->Params->Values["ColumnMetadataSupported"] = "False";
Form1->FDConnection1->Params->Values["Database"] = System::Ioutils::TPath::Combine(System::Ioutils::TPath::GetDocumentsPath(), "local.db"); // i'm using ifdefs to set this properly for platform (not shown)
query->SQL->Text = "SELECT DISTINCT committee FROM mtgs ORDER BY committee";
query->Open();
while (!query->Eof) {
Form1->cmbBoxFilters->Items->Add("Show " + query->FieldByName("committee")->AsString);
query->Next();
}
p.s. I'm building in C++Builder 10.2 Version 25.0.29899.2631 and the app is for Win32, iOS, and Android. I'm using FireDAC to access the db. The committee field is type TEXT. The TFDConnection setting for Driver is SQLite. The db file is SQLite version 3 (SQLite3).
UPDATE 1: I have been using SQLiteManager to import CSV data into my db. I've set it to UTF-8, UTF-16, and UTF-32 and all give the same result. The CIGRÉ gets converted to CIGR... by SQLiteManager. This is clearly not a problem with my code. I apologize for wasting folks time.
Related
I'm putting together a report in the BI Publisher Word .rtf plugin with very specific layout needs. One of those needs is the ability to switch company logos depending on parameters entered. I've been using conditional fields to selectively display each logo, but for some reason I can't reference data fields in the conditional code.
I've used these methods:
<?if: column_name = 'desired_value'?> [logo1] <?end if?>
<?choose:?><when: column_name = 'desired_value'?> [logo1] <?end when?>
Both of these methods seem to work when given raw values (i.e. instead of column_name = desired_value, I used 1=1 and it printed) but not when I use the name of the column I'm trying to compare.
For a more concrete example:
<?if: p_jno_in > 0?>
is always false, as if p_jno_in is null rather than having a value. (this variable represents the job number of the report and will never be null, even in my test data/sample xml.)
EDIT: Here is an example of what I've used, and the output.
If you host the image on the server, you can do all sorts of stuff with BI Publisher logic and concatenating an image path string. Make sure you or your DBA makes the path readable by BI Publisher. They can also map it to an FTP connection so you can edit/add images without being in Unix.
Insert any dummy placeholder image in RTF template (Insert Picture)
Right click on image and click “Edit Alt Text” and enter dynamic path. (See below for example)
url:{concat('${OA_MEDIA}/XX_LOGOS',/XML_PATH/LOGO_NAME,'_','small','.jpg')}
Other older versions of Word may have this data stored in the Size/AltText or Format Picture/Web menus
I looked around a bit and found the answer to my question. Turns out I was actually using the correct format the whole time! The issue was actually that I was referencing fields inside a for-each grouping, which I think might limit the scope. So, for example, if my BI Publisher data model has a query block A that has been split into two groups AA and AB, trying to reference a field from AA when you're in a for-each looping on an element from AB will not work.
I'm trying to pass text variables as parameters using htmldb_Get. Unfortunately when I'm updating or inserting rows whitch contains accented characters like é the result in the database will be Ê. I'm only developing this application for the firm so any solution altering the installed database or APEX properties won't help.
JS code:
var ajaxRq = new htmldb_Get(null,&APP_ID.,'APPLICATION_PROCESS=updateCategory',0);
ajaxRq.addParam('x01','é');
ajaxRes = ajaxRq.get();
Using Delphi 2007.
We do not use the designer to configure our DataSet. It is built automatically from the SQL query. So we need a solution where the fields are built at runtime.
I need to SELECT a large number (e.g. 2305843009213693951) from a NUMBER(19,0) column in Oracle using ADO. Our query works in SQLServer where the column is defined as BIGINT and is mapped automatically to a TLargeintField but for Oracle it is mapped to TBCDField. This behaviour is documented in a couple of places for instance here - TADOQuery.EnableBCD.
The problem (as mentioned in the same page) is that our number is in some instances too large and an overflow exception is thrown (it uses decimal under the hood). As expected / documented - if I use TADOQuery.EnableBCD(false) then the column is mapped to a TLargeintField which is what I want. However this option is set for all columns and seems a bit heavy handed.
An alternative is described:
Note: For fields with very large numbers of more than 19 significant digits, you can use TVariantField type persistent field objects. The TFloatField and TBCDField classes lack sufficient capacity for fields of this size. TVariantField allows the getting and setting of the field data as strings, preventing without loss of data due to insufficient capacity. However, arithmetic operations cannot be performed on numbers accessed through a TVariantField object.
So I tried configuring the fields to columns manually as described in this article - Creating a ClientDataSet's Structure at Runtime using TFields. But this doesn't appear to work as I get the exception: "Type mismatch for field 'total_rec' expecting: LargeInt actual: BCD'.
So is there a way to force ADO to return the dataset with a field of type TLargeintField for a NUMBER(19,0) without using the designer?
Interestingly ODAC maps the column to TLargeintField, but we are supposed to support ODAC and ADO.
I don't believe there is a way to manually control column data types returned by the ADOQuery. I tested overriding the procedure mentioned by kobik which determines the data type and this worked well. However we are not going to use this solution because I looked at the same code in XE4 and it appears it has been modified for use with large BCD numbers. We can wait until we upgrade from 2007 (hopefully next year).
The code I added to my overridden version of InternalInitFieldDefs was:
After
if (F.Type_ = adNumeric) and (F.NumericScale = 0) and (F.Precision < 10) then
begin
FieldType := TFieldType(ftInteger);
end
I added
else if (F.Type_ = adNumeric) and (F.NumericScale = 0) and (F.Precision >= 19) then
begin
FieldType := ftLargeint;
end;
I have an NCLOB field in the database, which I use to save data created using the fck editor.
Certain Turkish characters are displayed as numerical codes after doing an Oracle select from this NCLOB field . For example: the Ç character becomes Ç.
How can I solve this without having to use text replacement?
Who will use the data that is retrieved from the database after the select? If it will be displayed using the FCK editor, there should be no problem.
Otherwise, you need to use a different encoding (I don't know about FCK editor so I don't know if this is possible).
Or, you need to use a different editor (other than FCK) that will read/write in the proper encoding.
Therefore, decide who will be using the data; that is, what software will they be using to display the data coming from the NCLOB field (for example, Microsoft Word, Notepad, or some other application).
Using that application, create a file that contains Turkish characters.
Write that file into a NCLOB field.
Retrieve the file back and try to display it using the same application.
Make sure the characters are the same and that Oracle has not transformed the Turkish characters.
If all works well, use that application to store data into NCLOB fields.
I have one field when importing that can contain large data, it seems that CSV has unofficial limitation of about 65000 (likely 65535*) character. as both libreoffice calc and magento truncating the data for that particular field. I have investigated well and I'm certain it is not because of a special character or quotes. the data pretty straight forward, the lines are similar in format to each other.
Question: How to increase that size? or at least where I should look to find it?
Note: I counted in libreoffice writer and it was about 65040. but probably with carriage return characters it could reach 65535
I change:
1) in table catalog_category_entity_text
type of field "value" from "text" to "longtext"
2) in file app/code/core/Mage/ImportExport/Model/Import/Entity/Abstract.php
const DB_MAX_TEXT_LENGTH = 65536;
to
const DB_MAX_TEXT_LENGTH = 16777215;
and all OK
You are right, there is a limitation in Magento, because it sets texts fields as TEXT in MySQL database and, according to MySQL docs, this kind of field supports a maximum of 65535 chars.
http://dev.mysql.com/doc/refman/5.0/es/storage-requirements.html
So you could change the column type in your Magento database to use MEDIUMTEXT. I guess the correct place is in the catalog_product_entity_text table, where you should modify the 'value' field type to match your needs. But please, keep in mind this is dangerous. Make a full backup before trying. And you may even need to play with core files... not recommended!
I'm having the same issue with 8 products from a list of more than 400, and I think I'm not going to mess with Magento core and database, we can reduce the description strings for those few products.
The CSV could care less. Due to Microsoft Access allowing Memo fields which can contain quite a bit of data, I've exported 2-3k descriptions in CSV format to be imported into Magento quite successfully.
Your limitation is either because you are using a spreadsheet that has a cell limitation or export limitation on cells or because the field you are trying to import into has a maximum character limitation set in its table for that field.
You can determine the latter by using phpMyAdmin to see what the maximum character setting is for that field.