Using Power Query to query Kusto and the query times out after 5 minutes even though I've set the timeout to 21 minutes, like this:
[Timeout = #duration(0,0,21,0), ClientRequestProperties = [#"query_language" = "csl"]])
The query in question typically takes about 7-10 minutes when run directly in Kusto.
A similar question asked here had an answer that suggested going to "Data source settings" and clicking on "Change Source..." but that button is grayed for me. Besides, the above, query-specific setting should override a global setting, right?
Assuming that you're using the AzureDataExplorer.Contents() or Kusto.Contents() methods, there was a regression in the Timeout implementations of the connector. This was fixed on Jun 7 2021, and should be included in version 3.0.52 of the connector (should already be publicly available - make sure you have the latest version of the PBI Desktop).
If you're still facing an issue, contact me directly at itsagui(at)microsoft.com
I keep receiving an error message that my IF statement has too many arguments. I have used this formula in other excel workbooks and it has worked. Can anyone see what the problem is? Thank you for your help!
=IF(OR(AD2="22",AD2="23",AD2="39",AD2="540",AD2="541",AD2="836"),"1",IF(OR(AD2="335",AD2="312",AD2="364",AD2="367",AD2="311",AD2="336",AD2="365",AD2="319",AD2="368",AD2="488",AD2="498",AD2="461",AD2="501",AD2="505",AD2="531",AD2="462",AD2="489",AD2="491",AD2="491",AD2="493",AD2="507",AD2="457",AD2="460",AD2="499",AD2="503",AD2="509",AD2="513",AD2="539",AD2="612",AD2="613",AD2="568",AD2="821",AD2="827",AD2="829",AD2="835",AD2="845",AD2="846",AD2="615",AD2="620",AD2="614",AD2="691",AD2="719",AD2="873",AD2="877",AD2="32",AD2="427",AD2="373",AD2="465",AD2="502",AD2="511",AD2="466",AD2="475",AD2="481",AD2="500",AD2="504",AD2="462",AD2="489",AD2="491",AD2="493",AD2="507",AD2="503",AD2="513",AD2="539",AD2="607",AD2="610",AD2="608",AD2="609",AD2="611",AD2="579",AD2="769",AD2="795",AD2="827",AD2="831",AD2="834",AD2="837",AD2="838",AD2="839",AD2="840",AD2="841",AD2="842",AD2="843",AD2="851",AD2="852",AD2="853",AD2="854",AD2="856",AD2="857",AD2="860",AD2="861",AD2="868",AD2="869",AD2="870",AD2="871"),"2",IF(OR(AD2="521",AD2="524",AD2="535",AD2="536",AD2="557",AD2="558",AD2="805"),"3","4")))
It seems that the error probably has to do with the limits of version you are using.
Since the formula contains fixed equivalences, I suggest to create a Define Name range then Vlookup cell AD2 to the table in order to obtain the related value:
=IFERROR(VLOOKUP(AD2,_Table,2,0),"4")
This formula should work fine in Excel 2007 and later (I just tested it in 2010 with no issues). The maximum number of arguments allowed in a function in these versions is 255. For earlier versions of Excel though, the max is 30. Since you did not specify which version of Excel you are using, I cannot be 100% sure if this is the problem though but I suspect this is what is going on. I recommend you upgrade to a more current version of the software, but if that's not an option you could always break out the function among multiple cells (In particular, it's the 2nd nested if statement, with ~90 parameters that is causing this...).
I'm attempting to set up an OpenCart store for a client.
I'm getting the following error on the shipping page.
"Warning: No Shipping options are available. Please contact us for assistance!"
Research suggests that this error happens when there is a mismatch between the weight-class for the store and for the plugin, or something similar.
I've tried every combination of configuration settings that I can think of without result.
I'm not familiar enough with OpenCart to debug this issue. Where do I need to start looking?
Firstly you have to enable the shipping status and the values from admin panel shipping tab.After that you can get it in the front end.
My troubleshooting procedure:
The store weight UOM had been set to ounces.
The Fedex plugin doesn't support ounces as a weight UOM.
Nothing works.
The store weight UOM was changed to LBS.
Nothing works.
The package size was set to FedEx 10 KG Box
The Fedex plugin can't convert from Lbs to KG on the fly.
The package size was changed to "Fedex Box", without a weight class
Some products now working, all shipping estimates are WAY high.
When changing the default UOM for the store, no existing weights are converted in to the new units, although any weights stored without a unit are now read as being in the new unit.
This meant that the fedex system was trying to pull prices for items that "weighed" hundred of ounces (which it should have been able to do, even though those weights were incorrect.)
I updated the weights on all products to be in line with their unit of measure
At this point, the plugin was working for most, but not all, products, with reasonable accuracy.
I changed the plugin settings from List Rate to Account rate.
Now everything works.
To simplify - The fedex shipping plugin in opencart 1.5.6 will only work if:
All the products in the system have their weights stored in the same UOM.
That UOM is either pounds or kilograms (not ounces!)
A geozone is set, and a zip code is supplied(zip codes are important!)
The package size matches the unit of measure for the weight (no mixing kilograms and pounds!)
The product weights are actually correct
The account in question has a rate for a package of the indicated size
Hopefully someone else will find this helpful.
Ive been through this problem as well and I haven't yet fixed it completely.
But in my particular problem, I had a syntax error in the XML retrieved by the Fedex server after the cURL request.
Printing the $response variable I could find some good hints about some of the problems, for example, commas (,) instead of dots (.) to refer to decimal numbers and decimal numbers where it was expecting an integer.
So var_dump($response) could help some people find their specific issues.
I am working on a sitecore site rev 120706 DMS and main.
We are adding personas to some pages and getting unusual results with fractional values when we try to add to them using the Score(string, float) method. we have a value lead which is 0.5 due to two profiles being added to an earlier page one with a value of 1 and another with a value of 0. On a form submission we want to add one to the value and use Profile.Score("lead", 1) which replaces the .5 with a 1 instead of adding 1 to get 1.5 . When the value is 1 we are successfully getting 2.
How can we get the Score method to react in a consistent matter?
Sitecore apparently has an issue in their code with it using int.Parse instead of float.Parse
I've found place in the code where the error appears. It's in the
Sitecore.Analytics.Data.VisitProfile.Parse() method. It uses int.Parse
instead of float.Parse while reading profile values from database.
This issue was fixed in Sitecore 6.6.0 Update-4. Please see reference
number 376088 in release notes. Unfortunately, there is no easy way to
fix the code. Please consider upgrading your solution to 6.6.0
Update-4. In the meantime I would suggest to use larger score values
in your profiles, so that resulting value is always be greater than 1.
This approach works on my side. Please let us know in case you have
any troubles with that.
To resolve the issue ended up just multiplying the values we were using by 10 to avoid sitecore's int as opposed to float issue.
I've had a query that has been running fine for about 2 years. The database table has about 50 million rows, and is growing slowly. This last week one of my queries went from returning almost instantly to taking hours to run.
Rank.objects.filter(site=Site.objects.get(profile__client=client, profile__is_active=False)).latest('id')
I have narrowed the slow query down to the Rank model. It seems to have something to do with using the latest() method. If I just ask for a queryset, it returns an empty queryset right away.
#count returns 0 and is fast
Rank.objects.filter(site=Site.objects.get(profile__client=client, profile__is_active=False)).count() == 0
Rank.objects.filter(site=Site.objects.get(profile__client=client, profile__is_active=False)) == [] #also very fast
Here are the results of running EXPLAIN. http://explain.depesz.com/s/wPh
And EXPLAIN ANALYZE: http://explain.depesz.com/s/ggi
I tried vacuuming the table, no change. There is already an index on the "site" field (ForeignKey).
Strangely, if I run this same query for another client that already has Rank objects associated with her account, then the query returns very quickly once again. So it seems that this is only a problem when their are no Rank objects for that client.
Any ideas?
Versions:
Postgres 9.1,
Django 1.4 svn trunk rev 17047
Well, you've not shown the actual SQL, so that makes it difficult to be sure. But, the explain output suggests it thinks the quickest way to find a match is by scanning an index on "id" backwards until it finds the client in question.
Since you said it has been fast until recently, this is probably not a silly choice. However, there is always the chance that a particular client's record will be right at the far end of this search.
So - try two things first:
Run an analyze on the table in question, see if that gives the planner enough info.
If not, increase the stats (ALTER TABLE ... SET STATISTICS) on the columns in question and re-analyze. See if that does it.
http://www.postgresql.org/docs/9.1/static/planner-stats.html
If that's still not helping, then consider an index on (client,id), and drop the index on id (if not needed elsewhere). That should give you lightning fast answers.
latests is normally used for date comparison, maybe you should try to order by id desc and then limit to one.