I have noticed that when we use F_RoundToEven UDF from FreeAdhocUDF, that it fails to produce a correct result with certain numbers.
For example, the query:
select
F_RoundToEven(21.145, 2) Correct,
F_RoundToEven(215.145, 2) Fail
from Rdb$Database
produces the result:
CORRECT FAIL
21.14 215.15
Obviously these two number should both resolve to .14
Has anyone else come across this problem, and perhaps found a way around it?
I am using the latest version of FreeAdhocUDF with Firebird 2.1 and it fails on both Windows 32bit and Linux 64bit.
Thanks.
Related
Using PostgreSQL and PostGIS I get an error when using ST_OffsetCurve for some specific line geometries:
"lwgeom_offsetcurve: noded geometry cannot be offset"
Example:
SELECT ST_OffsetCurve(ST_GeomFromText('LINESTRING(288249.918098328 5615135.51135102,288293.425429089 5615086.62800628,288231.885629119 5615155.77174104,288249.918098328 5615135.51135102)'), -5.6875)
This is a closed line and the last three points are on a straight line.
PostGIS version is 3.0 on Windows.
Changing any coordinates or even just the offset value slightly removes this error.
Is it possible to prevent the error without changing numeric values?
Update to PostGIS version 3.1 solved the issue.
maybe ST_MakeValid fix this problem
https://postgis.net/docs/ST_MakeValid.html
And it is also better to pass srid as second parametr in ST_GeomFromText
SELECT ST_OffsetCurve(ST_MakeValid(ST_GeomFromText(...., your srid)), -5.6875)
Background
Ubuntu 18.04
Postgresql 11.2 in Docker
pgAdmin4 3.5
Have a column named alias with type character varying[](64). Values have already been set on some rows before using psycopg2. Everything was alright then.
SQL = 'UPDATE public."mytable" SET alias=%s WHERE id=%s'
query = cursor.mogrify(SQL, ([values] , id))
cursor.execute(query)
conn.commit()
Recently, when I want to add more value using pgAdmin GUI as shown in the first figure, the error in the second figure happens, which says Argument formats can't be mixed:
Well, it turns out if insert the values using script such as psql or query tool in pgAdmin, the error does not happen, i.e., it only happens if using GUI of pgAdmin.
Example script:
UPDATE public."mytable" SET alias='{a, b}' WHERE id='myid'
But as the GUI is much easier to modify values, so really want to figure it out. Any idea?
It's a bug in pgAdmin 4.17.
It looks like it happens whenever you edit a char(n)[] or varchar(n)[] cell in a table (although char[] and varchar[] are unaffected).
It should be fixed in 4.18.
In the meantime, you can fix it yourself without much trouble. The pgAdmin4 backend is written in Python, so there's no need to rebuild anything; you can just dive in and change the source.
Find the directory where pgAdmin4 is installed, and open web/pgadmin/tools/sqleditor/__init__.py in an editor. Find the line:
typname = '%s(%s)[]'.format(
...and change it to:
typname = '{}({})[]'.format(
You'll need to restart the pgAdmin4 service for the change to take effect.
I wasn't able to get this working with the Character Varying data type but it worked once I converted the column data type to Text.
I have a table with a column which can sometimes contain strings and sometimes elements of the form `s#(`s#`timestamp$())!`symbol$(). However, whenever I run a select from the table using q studio, it gives the response (trueb;kx.c$Flip#eeaaafe;`sym1`sym2) even though it works perfectly fine in the q console. I tried disabling the wrapping but then it just gives the result ([] column_names).
Sample code:
q)([]col1:`row_1`row_2`row_3;col2:(118718;`s#`s#2018.04.04D07:30:00.000000000 2018.04.04D07:45:00.000000000!`value1`value2;`s#`s#2011.02.03D00:00:00.000000000 2018.06.06D00:00:00.000000000!123456 0N))
col1 col2
--------------------------------------------------------------------------------------
row_1 118718
row_2 `s#`s#2018.04.04D07:30:00.000000000 2018.04.04D07:45:00.000000000!`value1`value2
row_3 `s#`s#2011.02.03D00:00:00.000000000 2018.06.06D00:00:00.000000000!123456 0N
The reason this didn't work was that the java interface interprets the result as a different type when it's sorted. Perhaps this is fixed in newer API versions. Either way as Jonathon mentions it is fixed in qStudio version 1.43 and up.
If anyone else finds bugs please report to:
http://www.timestored.com/contact
As I don't always check SO.
I'm trying to build a list of percentages in grafana, but am having trouble getting divideSeries+wildcards to work right.
I found Grafana dividing 2 series which seemed like what I wanted, but unfortunately there's no mapSeries function in my grafana instance (version 4.6.0-1).
This is what I've got, but instead of specifying the ID "1234", I want to use a wildcard, and have each ID grouped together.
divideSeries(stats.dhcp.pools.1234.cur,stats.dhcp.pools.1234.max)
Logically, I tried: divideSeries(stats.dhcp.pools.*.cur,stats.dhcp.pools.*.max) -- but that does not work. I tried mucking around with asPercent, but it has the same limits as divideSeries does.
I think applyByNode is what I want, but I can't seem to translate the example into something that actually works.
You use graphite as datasource (I think). Functions you mentioned are implemented in graphite-web, you can find docs also for applyByNode
applyByNode(
stats.dhcp.pools.*.*,
3,
'divideSeries(%.cur, %.max)',
'% pct'
)
Note that as of November 2017, applyByNode is not in the default graphite-api install, and requires installation from the github source:
pip install git+git://github.com/brutasse/graphite-api.git
As a side note - you can use any of graphite function, even mapSeries.
I Have created a stored procedure:
#DeviceID nvarchar(20) =''
WITH EXECUTE AS CALLER
AS
SELECT
amd.BRANDID,
amd.DEVICEID
FROM AMDEVICETABLE amd
where
left(amd.Deviceid,len(#DeviceID)) in (#DeviceID)
The length of amd.Deviceid is about 15 characters
In Visual Studio I create a parameter #DeviceID and when I am entering e.g ABCDE ( the first 5 characters from Deviceid) everything is working perfect.
the problem is that I want to put multiple values like
jhmcl*, jhmgd*.
So I created my own little version of your report and I believe the problem is your LEN() function. I'm surprised it doesn't return an error because it errors out in Report Builder for SQL Server 2014(simple version of SSRS). I would test what your LEN(#DeviceID) is returning. I would bet it's not returning the correct value. Instead you might try this to cover every possible pattern. I don't know how it will work performance wise.
SELECT DeviceID
FROM YourTable
WHERE LEN(DeviceID,1) IN (#DeviceID)
OR LEN(DeviceID,2) IN (#DeviceID)
OR LEN(DeviceID,3) IN (#DeviceID)
..
OR LEN(DeviceID,15),IN(#DeviceID)