I am importing some data using Import Set table and transform map. Data is being imported into cmdb_ci_computer table. This table have two fields (os and discovery_source) of type String, but both have choice list associated with them.
Now, when I create a field map for each of them, my source field is of type String (without choice list) and target field is of type String (with choice list). The Choice Action is set to "create".
When the transform happens, I get error message "Invalid Table assignment to the Choice record."
If I set Choice Action to "ignore", I don't get this error, but it neither sets value. I must set the value there.
How can I get rid of this error?
I was having same issue.I tried giving numeric value(as per the choice list of target table) and it will take that number as a string and insert accordingly(to choice list) to target table.
We encounter "Invalid Table assignment to the Choice record." error only when the source field and target choice list (in case of this question: OS and Discovery Source) are from two different scopes.
For example, if source field is created in application scope, and if target choice list is in Global scope, you will encounter this error.
If both - source and target - fields are from same source, you do not face this error.
More specifically, you will see this error when you are testing your scoped application on your dev instance only. Once your app is installed on some other instance (for testing purpose/actual deployment), you should not see this problem.
Related
Given a Julia object of composite type, how can one determine its fields?
I know one solution if you're working in the REPL: First you figure out the type of the object via a call to typeof, then enter help mode (?), and then look up the type. Is there a more programmatic way to achieve the same thing?
For v0.7+
Use fieldnames(x), where x is a DataType. For example, use fieldnames(Date), instead of fieldnames(today()), or else use fieldnames(typeof(today())).
This returns Vector{Symbol} listing the field names in order.
If a field name is myfield, then to retrieve the values in that field use either getfield(x, :myfield), or the shortcut syntax x.myfield.
Another useful and related function to play around with is dump(x).
Before v0.7
Use fieldnames(x), where x is either an instance of the composite type you are interested in, or else a DataType. That is, fieldnames(today()) and fieldnames(Date) are equally valid and have the same output.
suppose the object is obj,
you can get all the information of its fields with following code snippet:
T = typeof(obj)
for (name, typ) in zip(fieldnames(T), T.types)
println("type of the fieldname $name is $typ")
end
Here, fieldnames(T) returns the vector of field names and T.types returns the corresponding vector of type of the fields.
I have a dataset with data collected from a form that contains various date and value fields. Not all fields are mandatory so blanks are possible and
in many cases expected, like a DeathDate field for a patient who is still alive.
How do I best represent these blanks in the data?
I represent DeathDate using xsd:dateTime. Blanks or empty spaces are not allowed. All of these are flagged as invalid when validating using Jena RIOT:
foo:DeathDate_1
a foo:Deathdate ;
time:inXSDDatetime " "^^xsd:dateTime .
foo:DeathDate_2
a foo:Deathdate ;
time:inXSDDatetime ""^^xsd:dateTime .
foo:DeathDate_3
a foo:Deathdate ;
time:inXSDDatetime "--"^^xsd:dateTime .
I prefer to not omit the triple because I need to know if it was blank on the source versus a conversion error during construction of my RDF.
What is the best way to code these missing values?
You should represent this by just omitting the triple. That's the meaning of a triple that's "not present": it's information that is (currently) unknown.
Alternatively, you can choose to give it the value "unknown"^^xsd:string when there's no death date. The solution in this case is to not datatype it as an xsd:dateTime, but just as a simple string. It doesn't have to be a string of course, you could use any kind of "special" value for this, e.g. a boolean false - just as long as it's a valid literal value that you can distinguish from actual death dates. This will solve the parsing problem, but IMHO if you do this, you are setting yourself up for headaches in processing the data further down the line (because you will need to ask queries over this data, and they will have to take two different types of values into account, plus the possibility that the field is missing).
I prefer to not omit the triple because I need to know if it was blank
on the source versus a conversion error during construction of my RDF.
This sounds like an XY problem. If there are conversion errors, your application should signal that in another way, e.g. by logging an error. You shouldn't try to solve this by "corrupting" your data.
I have an SSIS package that obtains a list of new GUIDs from a SQL table. I then shred the GUIDs into a string variable so that I have them separated out by comma. An example of how they appear in the variable is:
'5f661168-aed2-4659-86ba-fd864ca341bc','f5ba6d28-7283-4bed-9f11-e8f6bef225c5'
The problem is in the data flow task. I use the variable as a parameter in a SQL query to get my source data and I cannot get my results. When the WHERE clause looks like:
WHERE [GUID] IN (?)
I get an invalid character error so I found out the implicit conversion doesn't work with the GUIDs like I thought they would. I could resolve this by putting {} around the GUID if this were a single GUID but there are a potential 4 or 5 different GUIDs this will need to retrieve at runtime.
Figuring I could get around it with this:
WHERE CAST([GUID] AS VARCHAR(50)) IN (?)
But this simply produces no results and there should be two in my current test.
I figure there must be a way to accomplish this... What am I missing?
You can't, at least not using the mechanics you have provided.
You cannot concatenate values and make that work with a parameter.
I'm open to being proven wrong on this point but I'll be damned if I can make it work.
How can I make it work?
The trick is to just go old school and make your query via string building/concatenation.
In my package, I defined two variables, filter and query. filter will be the concatenation you are already performing.
query will be an expression (right click, properties: set EvaluateAsExpression to True, Expression would be something like "SELECT * FROM dbo.RefData R WHERE R.refkey IN (" + #[User::filter] + ")"
In your data flow, then change your source to SQL Command from variable. No mapping required there.
Basic look and feel would be like
OLE Source query
I have an Installshield2010 project that has had this warning since before my employment
ISDEV : warning -3028: The string ID "IDS_ERROR_27555" was not found in the string table. It is referenced in the table:"Error" in column:"Message".
Looking in the svn history, this row was added to Error table a few years ago - alongside a seemingly unrelated change
<row><td>27555</td><td>##IDS_ERROR_27555##</td></row>
However as the error indicates, there is no corresponding entry in the ISString table.
I'm curious how it got added. The IDS_ERROR strings look like canned strings, it seems really unlikely the person who added this to my ism did so manually.
Of course Flexera's forums are a ghost town. I did find an ism that has that string defined as
<row><td>IDS_ERROR_27555</td><td>1033</td><td>Error attempting to apply permissions to object '[2]'. System error: [3] ([4])</td><td>0</td><td/><td>1394414478</td></row>
Do any of your ism's have IDS_ERROR_27555 defined or referenced? Am very sure I can delete the string and be no worse for wear... but it bugs me to not know what happened.
I don't remember in which version we added these strings, but you can get them by importing the strings file for your language (1033.txt for English) under the Languages folder. Upgrading across versions of InstallShield should have added this string. You can add them yourself by importing the strings file in the String Editor view. Of course if you've modified other strings, you'll want to ensure that you keep your preferred version.
I am having a problem with saving of data because of an incorrectly generated parameter name.
The table has a field "E-mail", and when the class wrapper is generated, the InsertCmd uses "#E-mail" as one of the parameters. In SQL Server, this is illegal and generated an exception.
I have hunted all over SubSonic for a way to modify the parameter name to simply "#Email" but the ParameterName property is read only.
I am using SubSonic 2.2 and don't have the source for it to make an internal modification.
Any ideas?
TIA
I got a mate of mine that uses SVN to pull the source code, and as expected, found a bug in the SS source.
When the column name is set in the class wrapper, the setter for the ColumnName property sets the ParamaterName property for you correctly using
"parameterName = Utility.PrefixParameter(Utility.StripNonAlphaNumeric(columnName), Table.Provider);". This removes any illegal characters like the hyphen in my E-mail column.
BUT... The property ParameterName is NOT used when the SQL commands are created. Here is the code in SQLDataProvider.GetInsertSQL, line 1462.
pars.Append(Utility.PrefixParameter( colName, this));
I changed this to
pars.Append(col.ParameterName);
and the problem is now sorted.
Thanks to you that came up with possible solutions.
You can modify the templates if you can't change the column name. See this blog post for details of how:
http://johnnycoder.com/blog/2008/06/09/custom-templates-with-subsonic/