I hava a problem with barcode in ireport. I use ireport 3.7.4 with berbecue and barcode4j library.
I want to put into the EAN128 barcode following data:
253 application Identifier (Global Document Type Identifier) value 24.1 (document type) + 2076764 (document id)
414 application Identifier (Global Location Number) value 2095
91 application Identifier (Company internal information) value 20110101.
I used component barcode4j and barbecue, unfortunately without effect.
Both like barbecue and Barcode4j component doesn't recognize 253 and 414 application identifiers.
Could anybody explain me why I'm wrong and write a correct code expression.
From Barcode4J EAN-128 document:
The allowed data types are "n" (numeric), "an" (alpha-numeric), "d"
(date) and "cd" (check digit).
I'm not sure whether you can put a dot in the data.
To locate the source of the error, try adding one part of the barcode data at a time.
Related
I have some trouble understanding the value of Time (0040,A122) tag. I am trying to update an anonymization software, but I can't seem to find any example of the actual tag.
The DICOM standard (PS 3.3) mentions that:
This is the Value component of a Name/Value pair when the Concept implied by Concept Name Code Sequence (0040,A043) is a time.
Note
The purpose or role of the date value could be specified in Concept Name Code Sequence (0040,A043).
Required if the value that Concept Name Code Sequence (0040,A043) requires (implies) is a time. Shall not be present otherwise.
So basically Concept Name Code Sequence (0040,A043) specifies what type of time it is? I would like to know what are some examples of Concept Name Code Sequence?
I would suggest to have a look at the SR sample given from the DICOM standard section PS 3.20:
A.7.2 Target DICOM SR "Measurement Report" (TID 1500)
In particular:
>>>>1.5.1.1.4: HAS ACQ CONTEXT: TIME: (111061,DCM,"Study Time") = "070844"
You may also want to check PS 3.16 for the definition of TID 1500:
TID 1500 Measurement Report
Just as a reminder, Enhanced SR are defined in PS 3.3:
A.35.2 Enhanced SR IOD
If I try to replace or cancel an order I get a message
58=Conditionally Required Field Missing
and the next message contains
58=Invalid MsgType
Here are the logs:
Replacing an order (tgFZctx200U61 is my side. FG is an exchange.):
20170203-15:44:04.225 : 8=FIX.4.49=15135=G34=349=tgFZctx200U6152=20170203-15:44:04.22556=FG1=U6111=270071221=138=240=241=2700744=11640054=155=RTS-3.1760=20170203-18:44:04.20510=028
20170203-15:44:04.225 : 8=FIX.4.49=23235=849=FG56=tgFZctx200U6134=352=20170203-15:43:56.98137=572984433198=F:572984433526=$01$11=270071241=2700717=exec-201702031001027616150=E39=E55=RTS-3.17461=FXXXXX54=138=140=2151=114=06=060=19700101-00:00:00.00010=213
20170203-15:44:04.275 : 8=FIX.4.49=11535=j34=449=tgFZctx200U6152=20170203-15:44:04.27556=FG45=358=Conditionally Required Field Missing372=8380=510=065
20170203-15:44:04.275 : 8=FIX.4.49=33335=849=FG56=tgFZctx200U6134=452=20170203-15:43:56.98237=572984753198=F:572984753526=$01$11=270071241=27007453=1448=tgFZctx200U61447=C452=317=3355471052150=539=01=FZ00U6155=RTS-3.1754=138=240=244=116400.00000336=9291151=214=06=060=20170203-15:43:56.98920008=-922337203685372211120018=[51000-3355471052-0]10=100
20170203-15:44:04.285 : 8=FIX.4.49=10335=349=FG56=tgFZctx200U6134=552=20170203-15:43:57.03345=4371=372373=1158=Invalid MsgType372=810=164
cancelling an order:
20170203-15:26:19.178 : 8=FIX.4.49=15435=F34=349=tgFZctx200U6152=20170203-15:26:19.17856=FG11=270061237=57286383038=141=2700644=116470.0000054=155=RTS-3.1760=20170203-18:26:19.17810=013
20170203-15:26:19.188 : 8=FIX.4.49=20735=849=FG56=tgFZctx200U6134=352=20170203-15:26:11.92437=572863830198=F:572863830526=$01$11=270061241=2700617=exec-201702031001027615150=639=655=RTS-3.17461=FXXXXX54=138=140=2151=114=06=010=239
20170203-15:26:19.418 : 8=FIX.4.49=11535=j34=449=tgFZctx200U6152=20170203-15:26:19.41856=FG45=358=Conditionally Required Field Missing372=8380=510=070
20170203-15:26:19.418 : 8=FIX.4.49=33335=849=FG56=tgFZctx200U6134=452=20170203-15:26:11.92437=572863830198=F:572863830526=$01$11=270061241=27006453=1448=tgFZctx200U61447=C452=317=3354681208150=439=41=FZ00U6155=RTS-3.1754=138=140=244=116470.00000336=9291151=014=06=060=20170203-15:26:11.93120008=-922337203685267353520018=[51000-3354681208-0]10=080
20170203-15:26:19.418 : 8=FIX.4.49=10335=349=FG56=tgFZctx200U6134=552=20170203-15:26:12.16445=4371=372373=1158=Invalid MsgType372=810=161
Best regards, Mikhail
"Conditionally Required Field Missing" means you are trying to extract an optional field that isn't present. (It's not required by the DD, but the user's logic expects it to be there, hence "conditionally required".)
The first 35=j message says:
45=3 - sequence number of message where these happened
58=Conditionally Required Field Missing
372=8 - type of message where this happened
380=5 - same code as explained in 58
Unfortunately, the message doesn't say which field is the problem, but basically, you're doing this (forgive my pseudocode):
var x = msg.getSomeOptionalField()
but you need to do this:
var x = null;
if (msg.checkIfSomeOptionalFieldIsPresent())
x = msg.getSomeOptionalField();
In order to parse your own FIX messages use FIXimate.
58 is a text field. The text after 58 in this case is the error message. The tag value pair 372=83 means: The message referred to (i.e. the missing tag) is tag 83.
Tag 83 is the sequence number of message within report series. FIXimate says that 83 is "Used to carry reporting sequence number of the fill as represented on the Trade Report Side."
This is your FIX engine sending an error back to the exchange. You can tell by looking at the SenderCompID and TargetCompID for each message.
You send a message:
20170203 15:44:04.225:8=FIX.4.49=15135=G34=349=tgFZctx200U6152=20170203-15:44:04.22556=FG
You get an Execution Report (35=8, probably acknowledging order cancellation/replace):
20170203-15:44:04.225 : 8=FIX.4.49=23235=8 49=FG 56=tgFZctx200U61lo9
You send an Business Reject (35=j):
20170203-15:44:04.275 : 8=FIX.4.49=115 35=j 34=4 49=tgFZctx200U61 52=20170203-15:44:04.275 56=FG 45=358=Conditionally Required Field Missing372=8380=510=065
What this last message coming in from the exchange is, is hard to tell without further analysis, but it most likely the execution report for the replaced order. It seems to have been sent 1 ms after the original execution report.
Your FIX engine expects certain data to be present within the messages. The expectation is set in your data dictionary, an xml file which should be provided by your counterparty. Sometimes (like now) there are errors in this file and you have to open it up, find the message in question (in this case the original execution report), and tell your data dictionary not to expect tag 83.
That should clear things up. Let me know if it doesn't work.
I am new to the FIX protocol and I am using QuickFIX to parse my FIX messages. Whenever I receive a Position Report message (AP), it gets rejected by the FIX engine with the below error:
Group 702's first entry does not start with delimiter 704
Here 702 is a group tag. I did some research and found that a repeating group message uses its first field as a delimiter. In my case group 702 is supposed to have either tag 704 (LongQty) or 705 (ShortQty). Only one of either tags will be present.
My counterparty is not sending the 703 tag. When the FIX engine sees there is no 704 tag in some cases, it rejects the message. Please let me know your suggestion to over come this problem.
FIX expects every group to start with a single consistent tag.
You can alter that tag in your XML DataDictionary, for instance, to use 704 instead of 703, by rearranging (or deleting/adding) the fields in that group.
In my case group 702 is supposed to have either tag 704(LongQty) or 705(ShortQty).
No, that won't work. Does it always start with 704 or does it always start with 705? It can't be one-of-either.
If your counterparty really is saying that it's one-of-either, then they are doing FIX wrong and we should publicly shame them. (Seriously, can't they just put 704=0 instead of omitting it?) To deal with this idiocy, you may have to hack the QF engine.
I suggest you double-check with your counterparty to confirm that they really are doing it wrong like this. I'm hoping (for your sake) that you are mistaken.
EDIT:
This is from the FIX 44 spec, Vol 1, page 19:
If the repeating group is used, the first field of the repeating group is required. This allows implementations of the protocol to use the first field as a "delimiter" indicating a new repeating group entry. The first field listed after the NoXXX, then becomes conditionally required if the NoXXX field is greater than zero.
I'm struggling with Solr search Arabic for several days and made some experiment. Here is the simple reflection of the problem.
After I store some Arabic sentence (now only 1 word السوري ) into database and have Solr index it, then query it by q=*:*&wt=python,(if no wt part, it was garbled chars) the response is:
'\u00d8\u00a7\u00d9\u201e\u00d8\u00b3\u00d9\u02c6\u00d8\u00b1\u00d9\u0160'
The actual word I store there for index is coding in another way:
'\xd8\xa7\xd9\x84\xd8\xb3\xd9\x88\xd8\xb1\xd9\x8a'
As you can tell, there is a one-to-to corresponding from \xd8↔\u00d8. But I don't know what is the name of this coding, thus I cannot convert it. And when I do the search as: <>/select/?q=السوري&wt=python,the response is:
{'responseHeader':{'status':0,'QTime':0,'params':{'wt':'python','q':u'\u0627\u0644\u0633\u0648\u0631\u064a'}},'response':{'numFound':0,'start':0,'docs':[]}}
No docs found and it seems using a third version for coding u'\u0627\u0644\u0633\u0648\u0631\u064a'. if I take it and encode('utf8') then it convert back to '\xd8\xa7\xd9\x84\xd8\xb3\xd9\x88\xd8\xb1\xd9\x8a'.
In summary, when it (السوري) is in my code (python) or in data base (mysql),
it presents as 'form1':
'\xd8\xa7\xd9\x84\xd8\xb3\xd9\x88\xd8\xb1\xd9\x8a'
When it is indexed by Solr, it converts to form2:
'\u00d8\u00a7\u00d9\u201e\u00d8\u00b3\u00d9\u02c6\u00d8\u00b1\u00d9\u0160'
And when I use <>/select/?q=السوري&wt=python, to query from browser (Google chrome), it becomes form3:
'\u0627\u0644\u0633\u0648\u0631\u064a'
(which could convert back to form1 by encode('utf8') But since they are different, the search matches nothing.
Therefore, those three different encode strategy may be the core problem. Could anyone help me figure it out and solve the search problem?
Thanks in advance.
I've opened a bug on Microsoft Connect for this, but no response (see edit below for their response) in a long while. So here it goes:
When trying to request an entity framework with its relation using the "Include" function in the linq query, it's impossible to request a relation through a path of more than 8 steps (8 . dot characters in the path). This prevents me from completing some of my dynmically generated queries that require access to more than that level of redirection.
Instead of completing the query successfully I get the following exception:
"Foo.Bar.Baz...(some more path string here)", the current limit of "8" is insufficient.
at System.Data.Common.MultipartIdentifier.IncrementStringCount(String name, String[] ary, Int32& position, String property)
at System.Data.Common.MultipartIdentifier.ParseMultipartIdentifier(String name, String leftQuote, String rightQuote, Char separator, Int32 limit, Boolean removequotes, String property, Boolean ThrowOnEmptyMultipartName)
at System.Data.Objects.Span.ParsePath(String path)
at System.Data.Objects.Span.Include(String path)
at System.Data.Objects.Span.IncludeIn(Span spanToIncludeIn, String pathToInclude)
Has anyone figured why this is so, or a way around this? Looking at the code (with Reflector) of ParsePath it seems that they hard-coded the magic number 8 in there...
UPDATE: Microsoft's response:
Thank you for raising this issue. We plan to remove the limit of the number of elements in an Include path in the next release.
UPDATE 2: Despite Microsoft's response quoted above, the bug was not fixed in EF 4.1
UPDATE 3: According to Microsoft, should be fixed in .NET 4.5, but I didn't test the developer preview to see if it works.
probably fixed in latest .net 4.5
https://connect.microsoft.com/VisualStudio/feedback/details/640423/entity-framework-include-strings-are-arbitrarily-limited-to-a-path-of-depth-8#tabs
I have not seen this, but here are 2 possible work arounds:
Loop through the data and use Load for each row. Note this will create a call to the database for each row, so it is really slow.
Flatten the data in a view and then select from the view. This creates a lot of redundant data, so more memory and network use.