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
Related
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
I've got a strange sybase behavior which I do not understand.
Situation
I have a table (MY_TABLE) with several columns of type smalldatetime. For illustration purposes let's assume the following table and data:
MY_TABLE||ID |TS_INIT |TS_LASTCHANGE |MY_TEXT |
||4711|3/31/2013 12:00:00 AM|3/31/2013 3:00:00 AM|someText|
TS_INIT and TS_LASTCHANGE are of type smalldatetime.
When executing the following statement I get the above result:
SELECT ID, TS_INIT, TS_LASTCHANGE MY_TEXT
FROM MY_TABLE
WHERE ID = 4711
go
My client is running in UTC+1 (Berlin) and has daylight savings time (DST) enabled.
I am not sure in what time zone the server is running and whether or not DST is enabled.
Problem
When I execute this (note that it is 03:00h):
SELECT ID, TS_INIT, TS_LASTCHANGE MY_TEXT
FROM MY_TABLE
WHERE ID = 4711 AND TS_LASTCHANGE = "2013-03-31 03:00:00:000"
go
I get NO results but when I execute this (note that it is 02:00h this time):
SELECT ID, TS_INIT, TS_LASTCHANGE MY_TEXT
FROM MY_TABLE
WHERE ID = 4711 AND TS_LASTCHANGE = "2013-03-31 02:00:00:000"
go
I do again get the above result which is saying TS_LASTCHANGE is
3/31/2013 3:00:00 AM
Note that the result prints 03:00h, even though I queried for 02:00h.
Why Is the first query returning no results even though there should be a match and why is the second query returning a result even though there should be no match?!
Note also that 3/31/2013 3:00:00 AM is the first moment in DST (at least in the year 2013) and 3/31/2013 2:00:00 AM should never ever exist at all because when transitioning from winter to summer time, the clock switches from 01:59:59 to 03:00:00 (as per this site).
Database: Adaptive Server Enterprise V15.0.3
Client: Aqua Data Studio V16.0.5
EDIT:
When querying whit the TS_INIT everything works as one would expect (only a result for 3/31/2013 12:00:00 AM)
Aqua Data Studio is written in Java.
The problem you are having has to do with the fact that Java is aware of timezones and databases don't have a concept of timezone when they store date and times. When the time comes back from the database, the database's JDBC driver puts it in a Java date and just assumes the timezone is irrelevant. The problem happens when you try to display a time which the JVM thinks is invalid, so a valid date is presented, which basically pushes the time by an hour. Daylight savings for 2015 started on March 08 2.00 AM and one of your rows contains a date which is invalid according to JVM.
This has been a known design issue with Java, and they are trying to fix this with JSR-310 for inclusion in Java SE 8. With this, they will have LocalDate, OffsetDate and ZonedDate. You can read more about it here ...
https://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html#jsr-310-datetime-concepts
https://jcp.org/en/jsr/detail?id=310
http://docs.google.com/View?id=dfn5297z_8d27fnf
Workaround
The only workaround, is to probably trick the JVM by setting the timezone in the JVM to GMT. If you are running ADS 16 on Windows, and you launch ADS with the shortcut icon on the desktop (which runs datastudio.exe), then you need to modify the datastudio.ini file in your folder. Add a new entry for vmarg.5=-Duser.timezone=gmt
This link explains the location of where to find the data studio.ini
https://www.aquaclusters.com/app/home/project/public/aquadatastudio/wikibook/Documentation14/page/50/Launcher-Memory-Configuration#windows
Once you have made the change, Restart ADS. Then go to Help->About->System: and double check your user.timezone setting and make sure it is GMT. Then give it a try.
With the above change there might be side effects in the application where timezone are involved, For e.g. in the Table Data Editor->Insert Current Date&Time, which would display a GMT time ... so there would be an offset.
so here's the thing.
I've got plenty of persisted "Snapshots" containing a java.sql.Timestamp and (for the sake of simplicity) an int as data.
I have a JSF page containing a primefaces 3.4.1 <p:lineChart> and behind that a ManagedBean that contains the model for the chart.
Let's say I then select a time range and fetch all the Snapshots in between that range.
and populate the data model for the chart with all the Timestamps (x-axis) and all the integers (y-axis).
So what i do while populating is:
data = new HashMap<Object, Number>();
List<Snapshot> allSnapshots = persistenceService.getAllSnapshots();
for(int i = 0; i < allSnapshots.size(); i++) {
Snapshot s = allSnapshots.get(i);
data.put(new Date(s.getTimestamp().getTime()), s.getData());
}
chartModel.getSeries().get(0).setData(data);
(Note: in the example code I just fetch all Snapshots, as I quickly just generated a hundred or so).
I set up the chart like this:
<p:lineChart id="chart" value="#{backingBean.chartModel}" xaxisAngle="-90">
<f:convertDateTime pattern="HH:mm:ss"/>
</p:lineChart>
It works ok but when the model contains a hundred data points, the xaxis is just overcrowded with all the tickmarks.
What I then did is to use the primefaces' option to use a jqplot extender function.
So I just add extender="extend" as attribute for the chart, where extend is the following js function :
function extend() {
this.cfg.axes = {
xaxis: {
renderer: $.jqplot.DateAxisRenderer,
rendererOptions: { tickRenderer: $.jqplot.CanvasAxisTickRenderer },
tickOptions: {
showGridline: true,
formatString: '%H:%M',
angle: -90
}
}
}
}
This is the current version of it..
After hours of reading and trial and error, I still cannot get it right, as the following things are just never right:
The tick marks never get rendered as the Date never gets converted.
At the moment this is just ignored and the formatString itself is
displayed...
Additional tick marks are created left and right of the actual data,
I dont want that.
When I only give autoscale: true as option for the jqplot extender,
I would expect just the spacing between the marks turn ok. But what
then happens is, that the spacing is cool but the original date
labels turn into just bare numbers starting from 0 to the amount of data available.. !?
I am getting a little tired from dealing with this.....maybe I am doing something fundamentally wrong. Otherwise I have no idea why this is so complicated..
Thanks for any advice!
Cheers
Chris
EDIT:
Ok thanks to perissf, I checked this one : https://stackoverflow.com/a/14287971/870122
With the suggested extender I get the following output :
http://www.abload.de/img/clipboard01y6sgj.png
(sorry I cannot post the image directly due to new user restrictions :-/ )
As you can see the tick marks are rendered correctly as HH:MM, thats very nice.
But as you also can see another quite weird problem occurs:
The given time range of the snapshots is
Start time: 2013-01-28 13:01:25.415
End time: 2013-01-28 13:14:32.145
I collected these as UTC timestamps with System.currentTimeMillis() while the JVM is set to UTC in the glassfish config.
As you notice, the datapoints in the plot are shifted one hour, they start at 14:01, which looks like the values have been auto-converted to my current timezone which is UTC+1. But the leftmost xaxis tick is placed at around the original UTC value at 13:00.
I collect the timestamps UTC as I dont know in which actual timezone the application will be running, but I'd like to display the "translated" time value. So the auto shift to my timezone is a nice feature, but the xaxis scaling is actually not nice and weird.
Any suggestions how I get rid of that ?
Cheers
Chris
EDIT2:
Ok while debugging the rendered page with Firebug I stumbled upon the jqplot internal variables in the plot object, which seem to contain the min and max values for the xaxis.
Min is set to the original min UTC value which is around 13:00, and max is set to the shifted UTC+1 value around 14:15.
Somehow the min value is not shifted accordingly to the automatic timezone adjustments.
All other values, that is dataBounds, data itself and so on, are all shifted nicely by one hour.
I opened a issue at Bitbucket jqplot issue tracker
Let's see.
Bye
Chris
i finally debugged the jqplot renderer and found some lines of code that cause this behaviour.
For anyone interested, please find the bugfix in the comment section here:
Bitbucket issue tracker
Thanks for any help
I'm very interested in this fix but the issues on BitBucket are in a restricted area so I cannot access it. So I had myself to try to fix this AxisDateRenderer and fortunately I did :)
So the Primefaces (6.0) chart uses an old version of the JQPlot library. A bug in this version sets the minimum date axis bound being not the first value exactly, but a time older according to the locale time zone of the user browser. For example, if the first value is at 12:00 and your GMT is GMT+1, then the date axis bound minimum will be at 11:00 instead of 12:00 !
The minVale
The following line (in createTicks function) should bed replaced (note the code is written minified below)
ad = ad.getTime() + ad.getUtcOffset();
By the next line:
ad = Math.floor((ad.getTime() - ad.getUtcOffset())/r) * r + ad.getUtcOffset();
Non minified line to replace:
min = min.getTime() + min.getUtcOffset();
With:
min = Math.floor((min.getTime() - min.getUtcOffset())/tempti) * tempti + min.getUtcOffset();
Note that I have tried to update the chart.js of Primefaces to an earlier version , but the chart do not work anymore. I will wait for the next update of Primefaces hoping that a newer version is used. I also don't know which version of JQPlot is used in Primefaces 6.0
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.
To all those who have had experience with using the crf++ toolkit (refer: http://crfpp.sourceforge.net/)
Please find the error message which pops up on trying to execute the CRF++ training program:
CRF++: Yet Another CRF Tool Kit
Copyright (C) 2005-2009 Taku Kudo, All rights reserved.
encoder.cpp(280) [feature_index.open(templfile, trainfile)] feature_index.cpp(86) [max_size == size] inconsistent column size: 21 20 train.data
I'm not sure how to interpret the error message.
There are 20 features in my training file and the 21st token is the class value.
I have created the Crf++ template file as per the instructions on the site.
It looks like a training data format issue, make sure the number of columns are consistent across all sentences.
I got this error today, and found that crf++ toolkit just set tab character(\t) to default column separator whereas my train data file using one white space lead to error.
Some points to check:
1. Check if you have a new line after each sentence
2. Check if your columnar values does not contain any sp
Error suggests that your number of columns in rows are not same among all. Your maximum number of columns are 21 and that should be consistent through out the training file but crf_learn finds it 20 somewhere in your train.data training file. So locate such row and remove/repair it.