I've made a report in pivot table in Excel 365 file by using the Power Query script, whose acquires data data form .xmlx file (previously exported from D365) by a path imported by VBA macro to named cell ("filePath").
The Power Query code starts like that:
let
Ścieżka = Excel.CurrentWorkbook(){[Name="filePath"]}[Content]{0}[Column1],
Źródło = Excel.Workbook(File.Contents(#"Ścieżka"), null, true),
AxTable1_Table = Źródło{[Item="AxTable1",Kind="Table"]}[Data],
...
Next i have some filtering and column manipulaion. I cannot share file in cause of using the business data of standard production costs lines.
The problem is that despite perfect working on PCs with Office 365, there is no way to propery runn this file on a Excell 2016. What i get is a popup window with text by second step in executing the let lines:
[DataFormat.Error] The input couldn't be recognized as a valid Excel document.
Is there a differences in loading files between these two releases of Power Query and some guidelines to ensure the enquiry working on both?
Step by step, I excluded errors with the VBA macro. I checked the file operation on four different computers (2x D365, 2x Office 2016) with the same source data. The error is reproducible in the same software version.
I need to find a way to ensure data retrieval compatibility in different versions of Power Query.
I'm having a strange issue with exporting/updating/importing data in our on-premises Dynamics 365 (8.2). I was doing a bulk update of over 3000 records by exporting the records to an Excel workbook, updating the data in a specific column, then importing the workbook back into CRM. It worked for all of the records except 14 of them, which according to the import log was for the reason that "You cannot import data to this record because the record was updated in Microsoft Dynamics 365 after it was exported." I looked at the Audit History of those 14 records, and find that they have not been modified in any way for a good two months. Strangely, the modified date of the most recent Audit History entry for ALL 14 records is the exact same date/time.
We have a custom workflow that runs once every 24 hours on a schedule that automatically updates the Age field of our Contact records based on the value in the respective Birthday field. For these 14 records, ALL of them have a birthday of November 3rd, but in different years. What that means though is that the last modification that was done to them was on 11/3/2019 via the workflow. However, I cannot understand why the system "thinks" that this should prevent a data update/import.
I am happy to provide any additional information that I may have forgotten to mention here. Can anyone help me, please?
While I was not able to discover why the records would not update, I was able to resolve the issue. Before I share what I did to update the records, I will try and list as many things as I can remember that I tried that did not work:
I reworked my Advanced Find query that I was using to export the records that needed updated to return ONLY those records that had actual updates. Previously, I used a more forgiving query that returned about 30 or so records, even though I knew that only 14 of them had new data to import. I did so because the query was easier to construct, and it was no big deal to remove the "extra" records from the workbook before uploading it for import. I would write a VLOOKUP for the 30-something records, and remove the columns for which the VLOOKUP didn't find a value in my dataset, leaving me with the 14 that did have new data. After getting the error a few times, I started to ensure that I only exported the 14 records that needed to be updated. However, I still got the error when trying to import.
I tried formatting the (Do Not Modify) Modified On column in the exported workbook to match the date format in the import window. On export of the records, Excel was formatting this column as m/d/yyyy h:mm while the import window with the details on each successful and failed import showed this column in mm/dd/yyyy hh:mm:ss format. I thought maybe if I matched the format in Excel to the import window format it might allow the records to import. It did not.
I tried using some Checksum verification tool to ensure that the value in the (Do Not Modify) Checksum column in the workbook wasn't being written incorrectly or in an invalid format. While the tool I used didn't actually give me much useful information, it did recognize that the values were checksum hashes, so I supposed that was helpful enough for my purposes.
I tried switching my browser from the new Edge browser (the one that uses Chromium) to just IE as suggested on the thread provided by Arun. However, it did not resolve the issue.
What ended up working in the end was Arun's suggestion to just do some arbitrary edit to all the records and exporting them afterward. This was okay to do for just 14 records, but I'm still slightly vexed as this wouldn't really be a feasible solution of it were, say, a thousand records that were not importing. There was no field that ALL 14 Contact records had in common that I could just bulk edit, and bulk edit back again. What I ended up doing was finding a text field on the Contact Form that did not have any value in it for any of the records, putting something in that field, then going to each record in turn and removing the value (since I don't know of a way to "blank out" or clear a text field while bulk editing. Again, this was okay for such a small number of records, but if it were to happen on a larger number, I would have to come up with an easier way to bulk edit and then bulk "restore" the records. Thanks to Arun for the helpful insights, and for taking the time to answer. It is highly appreciated!
When you first do an import of an entity (contacts for example) you see that your imported excel contains 3 hidden columns (Do Not Modify) Contact, (Do Not Modify) Row Checksum, (Do Not Modify) Modified On.
When you want to create new instances of the entity, just edit the records and clear the content of the 3 hidden colums.
This error will happen when there is a checksum difference or rowversion differs from the exported record vs the record in database.
Try to do some dummy edit for those affected records & try to export/reimport again.
I could think of two reasons - either the datetime format confusing the system :( or the the community thread explains a weird scenario.
Apparently when importing the file, amending and then saving as a different file type alters the spreadsheet's parameters.
I hence used Internet Explorer since when importing the file, the system asks the user to save as a different format. I added .xlsx at the end to save it as the required format. I amended the file and imported it back to CRM..It worked
For me it turned out to be a different CRM time zone setting for the exporter and importer. Unfortunately this setting doesn't seem to be able to be changed by an administrator via the user interface.
The setting is available for each user under File->Options->Time Zone.
I have a problem when I try to add items to a new dataset to do a sentiment analysis.
I have a sentiment score scale from 0 to 10 and everything works perfectly for sentiment score from 0 to 9 but those associated to 10 can't be read despite the fact that I put maximal sentiment scale to 10.
Is there a special modification to do to my csv file so that google could recognise those rows ?
This is the error I got :
Invalid input found at row 2 of ... "Row parsing resulting in unexpected label name."
Thanks for your help !
You must save and import your .csv file with only two columns: 'text' and 'labels'. Make sure there are no more additional columns.
gs://tttttt-bucket/table_2jpg,table
gs://tttttt-bucket/table_l.png,table
You can test a file like this, just give the uri and label. I tested it works.
I am using ElasticSearch and Kibana to display some temperature and humidity values.
As you can see in the Discovered screenshot, three input data is pushed to ElasticSearch Server
Three humidity values are respectively 29.42, 29.4 and 30.1. Using these three data I created a visualize as following hyperlink shown.
Kibana Visualize Output
However, this output only shows 30 and 29 values. Do you know how to modify the precision of visualization??
Thanks in advance.
I found that this may be caused by my initial data input.
My initial data input are like 25, 26, etc. Therefore, Index Pattern might learn that my values do not have decimal.
I newly created an index and input data with decimals at the very beginning then this issue does not exist anymore.
However, this still sounds strange for me because type of humidity and temperature are both number (long). It should have already taken into account decimal. Strange.
I just imported over 20k items into magento.
The original data was from an access DB.
In the descriptions, all the " are showing as �
for example, the original description reads:
This arrangement is approx. 32" - 34" tall.
on the magento front-end it now reads:
This arrangement is approx. 32�-34� tall.
Reimporting the data is not an option.... I need to be able to either have this shown correctly in magento front-end using a hack or somehow replace all these characters with the proper characters in MySQL database, or somehow change the encoding...
Any suggestions would be appreciated.
Hi You need to save csv in utf-8 format before import
I ended up exporting all the descriptions, did a find/replace in notepad, saved it as utf-8. and re-imported them back in after other methods failed.
This wasn't what i wanted to go through again but i had no choice.