I am trying to take the value of a drop down I created in grafana, utilizing a query variable.
I am using SimpleJSON for my database.
I have tried this pattern where:
var is my variable that makes up the drop down menu
func is my function call for the database query that creates the graph
So then I wrote:
f.g.func[$var]
I get a Internal Server Error yet when I call func in kdb+ with the values directly, it works fine. So I think I'm passing in var incorrectly.
For grafana/kdb+ adaptor, the syntax is f.g.func["$var"]-- my above attempt lacks the quotes necessary
Related
I am setting a Variable in Grafana.
I want to create a Query, that only returns a subset of the labels with value app the ones I want to return are those ending in dev
My Query so far, returns all of the labels with value app successfully. However, I have been unable to successfully filter the values so that only a-dev b-dev and c-dev are returned.
How do I successfully apply regex (or alternative) to this query so that I can see the desired values?
Any help on this would be greatly appreciated!
I eventually figured out what I needed to do. Originally I was trying to use | to run regex on the results from label_values.
However, this format worked:
label_values({app=~".*-dev$"}, app)
and returned only a-dev b-dev c-dev as expected.
I'm trying to run a function in a PostgreSQL 11 server from Ignition (8.0.16) as a named-query and getting a column index error. Everywhere that has discussed this error with regards to Postgres shows it is an issue of the parameters provided and expected not matching in number.
It always shows as one more than the number provided as being out of range. Even when changed to use a different number of parameters.
I count 13 everywhere: Ignition parameters, test parameters, the function call in Ignition, the function definition, the table. Here is the function call from Ignition:
SELECT insert_run_data(
:speed_in,
:avg_speed_in,
:coater_num_in,
:coater_op_in,
:finisher_in,
:helper1_in,
:helper2_in,
:coater_down_in,
:current_downtime_reason_in,
:hanging_downtime_reason_in,
:tabcode_in,
:start_time_in,
:end_time_in
);
In the same named-query window, if I comment out the function call and try to write directly using the same parameters, it writes without issue:
insert into
nh_coater_tabcode_operator_data(
speed, avg_speed, coater_num, coater_op, finisher, helper1,
helper2, coater_down, current_downtime_reason,
hanging_downtime_reason, tabcode, start_time, end_time
)
values(:speed_in, :avg_speed_in, :coater_num_in, :coater_op_in,
:finisher_in, :helper1_in, :helper2_in, :coater_down_in,
:current_downtime_reason_in, :hanging_downtime_reason_in, :tabcode_in,
:start_time_in, :end_time_in
);
The function also runs fine from within PGAdmin.
Here are gists showing the SQL used to create the table and function, the stack trace from Ignition, and an image showing the named-query authoring window parameters matching:
create function gist
create table gist
stack trace of error gist
parameters in Ignition
The Ignition Designer seems to cache the function. So, if it is changed, you will need to save and reopen the project: open another then switch back or close and open a new designer window.
In a parameterized query issued from c# code to PostgreSQL 10.14 via dotConnect 7.7.832 .NET connector, I select either a parameter value or the local timestamp, if the parameter is NULL:
using (var cmd = new PgSqlCommand("select COALESCE(#eventTime, LOCALTIMESTAMP)", connection)
When executed, this statement throws the error in subject. If I comment out the corresponding parameter
cmd.Parameters.Add("#eventTime", PgSqlType.TimeStamp).Value = DateTime.Now;
and hardcode
using (var cmd = new PgSqlCommand("select COALESCE('11/6/2020 2:36:58 PM', LOCALTIMESTAMP)", connection)
or if I cast the parameter
using (var cmd = new PgSqlCommand("select COALESCE(cast(#eventTime as timestamp without time zone), LOCALTIMESTAMP)", connection)
then it works. Can anyone explain what # operator in the error is referring to and why the error?
In the case that doesn't work, your .Net connection library seems to be passing an SQL command containing a literal # to the database, rather than substituting it. The database assumes you are trying to use # as a user defined operator, as it doesn't know what else it could possibly be. But no such operator has been defined.
Why is it doing that? I have no idea. That is a question about your .Net connection library, not about PostgreSQL itself, so you might want to add tag.
The error message you get from the database should include the text of the query it received (as opposed to the text you think it was sent) and it is often useful to see that in situations like this. If that text is not present in the client's error message (some connection libraries do not faithfully pass this info along) you should be able to pull it directly from the PostgreSQL server's log file.
I need to be able to use variables in table names - I basically have the same set of tables used for different types of data, so I would like to just have one dashboard and swapping between all types instead of always having to set up multiple identical dashboards.
My query is something like:
select * from table_$variable_name;
Where my list of possible variable is something like cat, dog, bird
I can seem to make this work, if I only put the variable as shown above I get the following error
Error 1146: Table 'table_$variable_name' doesn't exist
If I enclose it in curly brackets, I get this error instead.
Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '{bird}' at line 1
(i.e. with the selected variable actually being visible this time)
I'm not sure if the issue is having underscores in the table names, I tried putting underscores around my variables too to check and I had no luck with that.
Another thing I tried was gradually adding on to the table name, so e.g.
select * from table_$variable;
Still returns an error, but I can see the table name starting to form correctly
Error 1146: Table 'table_bird_' doesn't exist
However, as soon as I add another underscore, the variable is not picked up abymore
```Error 1146: Table 'table_$variable_' doesn't exist``
I'm sure it's something silly I am missing in the syntax of the query - anyone has any suggestions?
Using this https://grafana.com/docs/grafana/latest/variables/templates-and-variables/ for reference
As #arturomp suggests, use
${var:raw}
At least in my case, this was the solution that worked.
I found double square brackets work. e.g.
Rather than
select * from table_$variable_name;
use
select * from table_[[variable_name]];
I am getting error while inserting data to pgsql with .net core entity framework
error is Input string was not in correct format
this is my query executing
INSERT INTO public."MedQuantityVerification"("Id","MedId","ActivityBy","ActivityOn","Quantity","ActivityType","SupposedOn","Note") Values(7773866,248953,8887,'7/14/2018 10:43:43 PM','42.5 qty',5,NULL,'I counted forty two {point} five.')
anyhow when I run that query directly to postgresql browser it works fine
looks like issue on c# side it is but not know what?
also issue is with {point}
this is how I executing the dynamic query
db.Database.ExecuteSqlRaw(query);
You have to escape the curly brackets:
{point} should be {{point}}
ExecuteSqlRaw utilizes curly braces to parameterize the raw query so if your query naturally includes them like OP's does the function is going to try and parse them. Doubling up the braces like in Koen Schepens' answer acts as an escape sequence and tells the function not to parse it as a parameter.
The documentation for the function uses the following example as to the purpose of why it does what it does:
var userSuppliedSearchTerm = ".NET";
context.Database.ExecuteSqlRaw("UPDATE Blogs SET Rank = 50 WHERE Name = {0}", userSuppliedSearchTerm);
Note that you'll want to use this to your advantage any time you're accepting user-input and passing it to ExecuteSqlRaw. If the curly brace is in a parameter instead of the main string it doesn't need to be escaped.