"The element does not have an origin value. This element must have a non-null origin value."
I used the Wizard Wizard (Microsoft gets no points for creativity on that name..) to create a new Wizard, and this best practice error was in the system-generated form.
I searched for answers, and the only suggestion I found was to restart the AOS. That wasn't an option in my case, so I thought I would post the solution I came up with.
Export the offending object. Import it over top of the original.
When it is imported, it will be assigned a non-null origin ID.
Related
I have an import interface (not coded by me) that imports XML data and creates LedgerJournalTable (1) and LedgerJournalTrans (1..n) records.
When handling LJT dimensions, the code first checks that the dimension exists in AX, then inserts the data in the dimension[x] field. However, in the case that the dimension doesn't exist, a warning is shown to the user after the import run ends, but the data is still inserted as is.
And when the user goes to the LJT line after the import is complete, the erronous value is shown in the dimension field. When the lookup/drop-down of this dimension is clicked, the lookup does not open and AX client hangs. Ctrl+break will recover it, but the lookup never opens. You can delete the value, save, and the problem will still persist. You can manually enter an existing value and save, and the problem will still persist.
Problem extends to the table browser also.
Any idea why this is happening and how can it be fixed, other than not saving the erronous value in the first place (I have no idea why this is done this way in the first place)?
Thanks in advance.
Let me know if I'm reading this correctly.
User runs some process to import LJ table/trans records from XML.
If a bad dimension is inside XML, it shoves the data into the LJ trans dimension[x] field even though it's invalid, and presents a warning to user.
User views the journal and sees the bad data and attempts to use the lookup to correct it, but the lookup hangs/crashes.
Seems to me the issue may be that you've been shoving a bunch of bad data into AX and the lookup is trying to use table/edt relations that are invalid.
If I'm right, you need to go to SQL directly and query the ledger trans table and look for any bad dimension data and correct/remove it.
I suspect existing bad data is causing the lookup to fail and not merely whatever bad data you imported and are looking at.
Perhaps what caused the problem is, a user imported bad data, received a warning, ignored warning, clicked "post" as-is (with bad data) and now it's in AX? And now when you do a 2nd import, and try to use the lookup, it's crashing on that bad-data-relation.
Edited: So, while there was an corruption in the DB, the actual culprit was found: the standard AX code creating temp data for the dimension lookup - there was a mod code in Dimensions.insert() that wrote an XML file every dimensions were updated or inserted. This took so long in this case that it hang up the client. I put the code inside an if clause like so:
if(!this.isTemp())
{
// offending code
}
Problem solved.
In Dynamics AX 2012, when trying to update the value of the field DlvMode or adding a new delivery address in the sales order (through the Header view), I keep getting this error:
Function SalesTable2LineField.lineUpdateDescription has been used
incorrectly
There's no customization in this method or this class.
This is something that could be debugged in 15 minutes if you had a developer. My guess would be that you are using one of these country codes:
AT,BE,CZ,DK,EE,FI,FR,DE,HU,IE,IT,LV,LT,NL,PL,ES,SE,GB,RU,MY (SalesTable_W)
BR (SalesTable_BR)
IN (SalesTable_IN)
In \Classes\SalesTable2LineField\lineUpdateDescription at the very end, immediately above the throw error... line add this:
info(strFmt("Offending table is %1 (%2)", tableId2name(tableId), tableId));
You should also add a breakpoint if that alone doesn't help and figure it out.
Then repeat the operation, and you will know the table. It's possible it's just a Microsoft bug or if \Forms\SalesTable has been modified, it could be that. You just need to debug it.
I'm trying to make an entity like vendor in ax 2012. When I click the "new" button I get following error;
Invalid field/related field combination.
I have looked for it on search engines and found out that it might be due to wrong joins used in data sources of the form. I have gone through the joins and links, they all are fine but I'm still getting the same error.
Any one, any idea?
Put a breakpoint in the info.add method to catch AX in the deed.
When I am publishing my page from tridio 2009, I am getting the error below:
Destination with name 'FTP=[Host=servername, Location=\RET, Password=******, Port=21, UserName=retftp]' reported the following failure:
A processing error occurred processing a transport package Attempting to deploy a binary [Binary id=tcm:553-974947-16 variantId= sg= path=/Images/image_thumbnail01.jpg] to a location where a different binary is already stored Existing binary: tcd:pub[553]/binarymeta[974950]
Below is my code snippet
Component bigImageComp = th.GetComponentValue("bigimage", imageMetaFields);
string bigImagefileName = string.Empty;
string bigImagePath = string.Empty;
bigImagefileName = bigImageComp.BinaryContent.Filename;
bigImagePath = m_Engine.AddBinary(bigImageComp.Id, TcmUri.UriNull, null, bigImageComp.BinaryContent.GetByteArray(), Path.GetFileName(bigImagefileName));
imageBigNode.InnerText = bigImagePath;
Please suggest
Chris Summers addressed this on his blog. Have a read of the article - http://www.urbancherry.net/blogengine/post/2010/02/09/Unique-binary-filenames-for-SDL-Tridion-Multimedia-Components.aspx
Generally in Tridion Content Delivery we can only keep one version of a Component. To get multiple "versions" of a MMC we have to publish MMC as variants. By this way we can produce as many variants as we need via templating.
You can refer below article for more detail:
http://yatb.mitza.net/2012/03/publishing-images-as-variants.html#!/2012/03/publishing-images-as-variants.html
When adding binaries you must ensure that the file and it's metadata is unique. If one of the values e.g. the filename appears to be the same but the rest of the metadata does not match, then deployment will fail.
In the given example (as Nuno points out) the binary 910 is trying to deploy over binary 703. The filename is the same but the binary is identified to be not the same (in the case a different ID from the same publication). For this example you will need to rename one of the binaries (either the file itself or change the path) and everything will be fine.
Other scenarios can be that the same image is used from two different templates and the template id is used as the varient ID. If this is the case it is the same image BUT the varient ID check fails so to avoid overwriting the same image the deployer fails it.
Often unpublishing can help, however, the image is only removed when ALL references to it are removed. So if it is used from more than one place there are more open references.
This is logical protection from the deployer. You would not want the wrong image replacing another and either upsetting the layout or potentially changing the content to another meeting (think advertising banner).
This is actual cause and reason for above problem (Something got from forum)
I currently have nodes setup on my site, and each node belongs to a particular menu (not primary or secondary prebuilt menues).
How can i find out which menu a node belongs to?
Maybe this is what you mean:
$trail = menu_get_active_trail();
$lastInTrail = end($trail);
$menu_name = $lastInTrail['menu_name'];
menu_get_active_trail() returns a breadcrumbs like array, the last breadcrumb represents the current node.
Cheers,
Laurens Meurs, Rotterdam
I'm a noob, so don't bash me if what I'm going to write is worthless babbling.
I think you can't do that directly, unless there's some smart module out there that would do all the nasty SQL queries necessary to check this.
Node info is stored in the SQL table "node", and is identified merely by NID (node ID, which is the node number that appears after /?q=node/ in the address). Their aliases, if any, are stored in "url_alias" table, where you can find columns "src" and "dst", identifying the original and the aliased path (for instance, src='node/123', dst='my/url/alias'). The menu links can be found in the table "menu_links", where you can find the columns "menu_name" (the machine-radable name of a menu) and "link_path" (either the node/... or the alias).
So, what you'd need to do is the following:
get the current node's NID
query "url_alias" if there's an alias for node/NID and retrieve it, otherwise leave node/NID
query the "menu_links" table for the path you've determined and retrieve "none" or the menu's machine-readable name
You could then also query the table "menu_custom" to check what's the human-readable name of the menu you've determined.
Anyway, that's a complicated query (several queries?) and I'm a MySQL ignorant, so I can't help you with the actual code you'll need to use to check all that :P.
This isn't a direct solution and I see from your reply to a previous answer that you didn't wanted the simplest solution possible, but I thought I'd mention this option. The Menu Node API module maintains a table which Drupal lacks, a node-menu relationship table.
The module does nothing on its own, but there seems to be contributed modules which build on this, so depending on how complex your problem is it might be a starting point.
http://drupal.org/node/584984
Updated: Sorry guys, didn't even realize I had posted this link. I think I intended it as a draft and simply posted it when closing tabs. That said, mingos (above) is right on.
My link is to a function menu_get_active_menu_name() that appears to provide you with an array containing the active menu for the current page. As I presume that is what you are using it for, it would be a nice way to abstract yourself away from the database calls that might cause problems down the line.
I myself have never tried it, which is probably why I didn't elaborate and post. well... at least didn't post on purpose.