I'm using REGEXP_EXTRACT function on Tableau trying to extract numbers from a string. My line of code:
INT(REGEXP_EXTRACT([Name], '([0-9]+)'))
My colleague can use it and I can't. Getting an unknown function error. We are both using the same version of Tableau, 10.0.1 and mine for some reason is unknown. Do I need to install some drivers or so to get it working? By the way, none of the regex_ functions work on my machine.
As you are using Amazon Redshift you cannot use the Tableau built in regex-functions. This is because the regex functions are not currently supported in tabelau for redshift. find out more here
In order to get around this you can:
1) Create a tableau data extract from your redshift data source and schedule this to update as required,
2) access them via the raw sql functions (see here)
Related
PostgreSQL has excellent support for evaluating JSONPath expressions against JSON data.
For example, this query returns true because the value of the nested field is indeed "foo".
select '{"header": {"nested": "foo"}}'::jsonb #? '$.header ? (#.nested == "foo")'
Notably this query does not reference any schemas or tables. Ideally, I would like to use this functionality of PostgreSQL without creating or connecting to a full database instance. Is it possible to run PostgreSQL in such a way that it doesn't have schemas or tables, but is still able to evaluate "standalone" queries?
Some other context on the project, we need to evaluate JSONPath expressions against JSON data in both a Postgres database and Python application. Unfortunately, Python does not have any JSONPath libraries that support enough of the spec to be useful to us.
Ideally, I would like to use this functionality of PostgreSQL without creating or connecting to a full database instance.
Well, it is open source. You can always pull out the source code for this functionality you want and adapt it to compile by itself. But that seems like a large and annoying undertaking, and I probably wouldn't do it. And short of that, no.
Why do you need this? Are you worried about scalability or ease of installation or performance or what? If you are already using PostgreSQL anyway, firing up a dummy connection to just fire some queries at the JSONB engine doesn't seem too hard.
I'm converting a process from postgreSQL over to DataBrick ApacheSpark,
The postgresql process uses the following sql function to get the point on a map from a X and Y value. ST_Transform(ST_SetSrid(ST_MakePoint(x, y),4326),3857)
Does anyone know how I can achieve this same logic in SparkSQL o databricks?
To achieve this you need to use some library, like, Apache Sedona, GeoMesa, or something else. Sedona, for example, has the ST_TRANSFORM function, maybe it has the rest as well.
The only thing that you need to take care, is that if you're using pure SQL, then on Databricks you will need:
install Sedona libraries using the init script, so libraries should be there before Spark starts
set Spark configuration parameters, as described in the following pull request
Update June 2022nd: people at Databricks developed the Mosaic library that is heavily optimized for geospatial analysis on Databricks, and it's compatible with standard ST_ functions.
This is a hybrid question & public service announcement. The basic question is whether there are convenient and/or efficient workarounds to the limitations listed below. I spent half the morning discovering that one cannot just transplant SQL code from Access to Matlab. I've boiled it down to 3 points so far.
Can't use double quotes in SQL statements to avoid collision with
Matlab's string delimiter. The Matlab code for the SQL code strings
can become quite complicated, especially if the SQL strings already
use repeated single-quotes to represent a single quote within a
string constant.
Must always specify a source table from which to query. What won't
work is "SELECT #2015-07-28#". One basically needs to create a 1-row dummy table.
Must always select at least one field in the table being queried.
An asterisk does not seem to suffice.
The above limitations do not exist when submitting SQL code using the Access Query Designer (either in SQL 92 mode or not), nor do these limitations exist when submitting SQL code using VBA via CurrentProject.Connection.Execute.
Hopefully, this saves someone else some time in learning about these differences. And if anyone has found a workaround, that would be appreciated. Note that the above is in the context of using the JDBC/ODBC bridge (3rd of 3 illustrated configurations in the drivers documentation. The database toolbox documentation for directly connecting to an Access file using code (rather than setting up a data source using the GUI) only describes a code pattern that uses the JDBC/ODBC bridge. This is described in Example "Connect to Microsoft Access Using a File DSN" in the "Connect to database" page. I'd like to stick to this approach because I want to quickly be able to directly specify the source *.accdb file without jumping through GUI hoops of setting up a data source.
I've posted this to:
Stack overflow
Usenet
While I have not connected Matlab to Access, I have connected Access databases to PHP, Python, SAS, R, even Excel without any issues with quotes or asterisk. As for the needed source table in queries that is simply due to the Jet/ACE SQL dialect as each dialect have their particular rules. But your query above should work for one-row, one-column output of such date. SQL Server does not require a source table but Oracle does. Access dates are in the MM/DD/YYYY format, requiring # in conditional statements. MySQL use dates in YYYY-MM-DD format, requiring single quotes.
Are you using Windows installed Jet/ACE ODBC drivers? Do note these drivers are softwares external to any application (not part of Access) and can be used by any client interfacing to any data source. Aside - many are not aware that Access' backend database engine, Jet/ACE is actually a Windows technology and not restricted to Access; PC users without Access installed can still use this engine. Hence, connection strings are standard across ODBC calls. And as I see you can apply same principles to Matlab database connections.
With that said, my suggestions/workarounds:
properly learn the SQL dialect for connecting database and check if query runs; even optimize or re-write as needed
try escaping various punctuation not compliant in Matlab strings or use the ASCII counterparts: chr(34) for double quote; chr(39) for single quote; chr(42) for asterisk.
if select statements are limited in Matlab strings, create a temp table from query (use make-table query SELECT * INTO newtable FROM query outside of Matlab), then connect to this new table
use intermediary coding language (VBA, Python, C#) by user trigger or
command line to connect to database and export needed dataset, then
automate Matlab to import
export query to flatfile format (csv, txt, etc.) for Matlab import
I am trying to run RAWSQL_REAL("select sum(amount_us)from gbsa_dpo_itg.Fact_tblHistoryData_new where qtr_data='Q42014'") in calculated field and I am getting error message ERROR 2133: Aggregate function calls cannot contain subqueries.
I am using tableau 8.3.3 and HP Vertica database live connection to tableau
When I run the same query in custom sql it is working fine
pleas help in this
thanks in advance
Read the manual about these functions, look under reference, functions
You don't generally pass an entire SQL string to execute in isolation. Instead, they are useful for writing expressions or calling non standard functions that your server may provide, which are embedded within the SQL that Tableau generates. So first learn to use Tableau to get the effect you want, and then resort to Raw SQL functions in the rare case where you need to access some database server specific feature.
There is no reason that you would need Raw SQL to get the information above using Tableau. You could put amount_us on the row shelf and qtr_data on the filter shelf, and Tableau would generate a similar query.
If you are doing this to combine data from multiple queries, first learn about calculated fields and data blending.
We are using tableau and we are connected live to a redshift data source.
I cannot seem to find the Median aggregate function that i see when i connect to other types of data sources. Is this a known issue? We can't seem to find anything about it. Can we overcome it somehow using some kind of custom function?
First, I'm not a Redshift expert. However I know in other cases when the underlying datastore doesn't offer Median (MySQL for example), then a direct Tableau connection can't find the median.
If you use a Tableau extract, "Median" should appear as an aggregation option. This is due to the fact that Tableau has a median in its own data store implmentation.