I've got a Text Input field with 'Allowed Content' set to 'Decimal'. It won't let me set it to anything over a million on an entry, giving the error number_exceeds_limit.
I've thought about saving it as a string rather than use the decimal content type but I need to display them in order using orderby on the field and if it is a string it will treat 9 and being greater than 100 since 9 is greater than 1.
Is there a way to either increase or get around the million limit?
Expressionengine version 3.5.2 in case it's relevant.
You would need to edit the logic in cp/ee/EllisLab/Addons/text/ft.text.php (line 62 in 5.1.2) and also edit the column type in the DB structure (I just tried this locally setting the field length to 20,4 instead of 10,4.
It is probably worth raising an issue about this on the EE github as that limit seems restrictive to me (mySQL supports 65 digits). https://github.com/ExpressionEngine/ExpressionEngine/issues
Related
I am teaching a man the basics of QGis for a project he needs to do at his work. He has very little computer knowledge and would like to standardise the work as much as possible (specific workarounds would complicate it too much for him). His QGis version is 3.16 "Hannover" and as this is a work laptop he does not have permission to download a newer version.
We have been having problem with one specific table. The first few rows are below, written exactly as they are originally.
Baum-Nr. Baumart BHD Alter Y X Biotopbaum Klassifizierung Bemerkungen
1 Buche 86 120 49.1356 11.0488 A Altbaum Freistellen !!!
2 Kiefer 45 100 49.13561 11.04883 Hlb,Bs,Th Höhlenbaum
3 Kiefer 32 100 49.13571 11.04579 Hlb,Sw,Th Höhlenbaum
4 Kiefer 74 120 49.13513 11.0495 A Altbaum
After adding it from Excel to QGis through "add vector layer", the header "Klassifizierung" becomes one of the coordinates and I believe one of the columns are switched (unfortunately, I can't remember specifics. This is a small side job and I haven't had time to look into it for days. I should have taken a photo, but this isn't possible anymore). We have attempted to copy the column into a new Excel document and transferring it to QGis again, and this time the headers were shoved one cell to the right such that "Y" was placed over "X" and "Biotopbaum" over "Klassifizierung", for example.
I could not find a way to fix the import problem in his laptop. He e-mailed me the problematic table and I opened it successfully in my QGis 3.26 "Buenos Aires".
I believe this may be a problem with his QGis version, but it is curious that we only encountered it with this one table. All other tables we have worked with have the same headers and the same kind of data on their respective rows.
Is this a known problem, or have other people faced similar situations? Could someone explain what could be causing it? Would there be a way to fix it such that we can successfully import the table without having to edit it in QGis? This is not a solution the man would accept.
Thank you in advance.
Remove the commas in the Biotopbaum field or replace them with a less common delimiter. In fact, remove all punctionation (e.g., Baum-Nr. >> remove the period ".").
Also save the table into a csv format and try to import.
I'm trying to insert timestamp with milli seconds into a database. I tried following steps but haven't had any luck.
Extend field value to milli seconds , with length 26 and scale 3.
Used StringToTimestamp(timestampInString,"%yyyy-%mm-%dd %hh:%nn:%ss.3"), Resulting null value in output.
Modified the default time Stamp in job properties to %yyyy-%mm-%dd %hh:%nn:%ss.3
Design :
Sequential file --> TX --> destination (SQL/Seq file)
Could you please assist a solution for this?
What you tried looks good so far with one exception:
length 26 and scale 3
Using Db2 for example you would need to specify length 26 precision 6.
26 and 3 do not fit as
%yyyy-%mm-%dd %hh:%nn:%ss has length of 20
Specifying microsenonds is extended attriute is also necessary.
Have a try and provide more details of the target system if you still have problems
try below command in transformer stage and set the target data type as per the requirement, it will give the required result:
StringToTimestamp(Columnname,"%yyyy-%mm-%dd %hh:%nn:%ss.3")
Most important thing is to override the default NLS settings in the job with expected format (%yyyy-%mm-%dd %hh:%nn:%ss.3) which you have already completed.
Now, for the microseconds part which is not being displayed, you can enable the Microseconds extended attribute for the field in the target stage used.
Also you can refer this link from IBM which explains a similar scenario
I have a Solr instance running with about 200 entries in its database. I want to search for strings with OR but fail to get a working query.
When running a simple query like this: q=fieldname:"string", i get 13 results. When running another query like this: q=fieldname:"otherstring", i gt 18 results. In the end i would expect it to be 27 results because together there are 31 results and 4 of the are the same ones as they contain both strings.
Problem now comes if i want to search both these strings at once it will return all kinds of results but not the expected 27. I found this site describing how it should work and tried a couple of different things:
q=fieldname:"string otherstring" gives me 10
q=fieldname:"otherstring string" gives me 0
q=fieldname:"string otherstring"~1 gives me 10
q=fieldname:"otherstring string"~1 gives me 1
q=fieldname:"(string otherstring)" gives me 37 but some are not related at all
q=(+fieldname:"string" +fieldname:"otherstring")" same as above
I could go on with this as i tried more if these combinations. Can anyone help me getting a query with the correct number of results or can anyone explain me what i am doing wrong?
If you want to perform an OR query, use OR explicitly:
q=fieldname:"string" OR fieldname:"otherstring"
The other versions will give varying results depending on the value q.op and the query parser in use.
q=fieldname:("string" OR "otherstring")
should be semantically identical.
I'm new to using Xdebug via the Vim plugin Vdebug.
I'm getting on OK, but I noticed that if I create an array with over 32 elements, the Watch window only shows elements 0-31 (i.e. the first 32). There does not seem to be a way to obtain the next 32, or to tell it to fetch all of them (or 1000 of them or whatever)?
Is this a bug/feature-lack in Vdebug? Is there anything I can do about it?
I'm debugging Drupal, which has very big, complex arrays (which sometimes contain recursive references #sigh), so at first I thought maybe it's iterating, getting in a loop and hitting max data limit. But I tried just looking at for ($i=0;$i<50;$i++) $a[] = $i; and this, too, only lists elements 0-31.
I have tried
let g:vdebug_features['max_depth'] = 1000
let g:vdebug_features['max_data'] = 1000000
but they have not made any difference.
Thanks,
After Vdebug is loaded, put this
let g:vdebug_features = { 'max_children': 128 }
Or whatever you'd like your max to be.
All credit to romaini for this answer as it was his comment that meant I found this problem listed as an issue on the vdebug github repo.
Is it in anyway possible to increase the number of suggests that your extension may show in the omnibox?
By default it looks like 5 rows is the limit. I've read about a command line switch to change the number of rows (--omnibox-popup-count) but I am really interested in dynamically being able to set this in my extension.
5 rows isn't really enough for the information my extension want to show.
[Update 2018 - thanx version365 & Aaron!]
» Not hardcoded anymore! chrome://flags/#omnibox-ui-max-autocomplete-matches . Credit goes to #version365 answering below: http://stackoverflow.com/a/47806290/234309 « – Aaron Thoma
..[historical] detail: since the removal of --omnibox-popup-count flag (http://codereview.chromium.org/2013008) in May 2010 the number [was] hardcoded:
const size_t AutocompleteResult::kMaxMatches = 6;
a discussion two years later on the chromium-discuss mailing list about the 'Omnibox default configuration' "concluded"
"On lower performing machines generating more result would slow down the result display. The current number look like a good balance."
[which is not a very valid argument, considering the probably infinitesimal overhead retrieving more items than the hard-wired number]
why the heck is there no chromium fork that removes stupid UX limitations like this (or the no tabbar in fullscreen mode)^^
Since there is no more --omnibox-popup-count flag; you can use another flag which is new.
chrome://flags/#omnibox-ui-max-autocomplete-matches lets you select a maximum of 12 rows.
In fact there is no more --omnibox-popup-count flag
http://code.google.com/p/chromium/issues/detail?id=40083
So I think there is no way to enlarge the omnibox.