I'm unable to utilize SQLite window functions (e.g. LAG, LEAD). After some investigation it seems that this is due to the fact that SQLite database version is below 3.25.0, after which window functions were made available.
Database created using SQLite 3.30.1 version
However version 3.24.0 version displayed on this 'test' database
When queries which include window functions are tested, such as the ones provided on sqlitetutorial site: the following errors are displayed
Could you please advise how to resolve this. I would much appreciate your support on this.
SELECT CustomerId, Year, Total,
LAG (Total, 1, 0) OVER (ORDER BY Year) PreviousYearTotal
FROM CustomerInvoices
WHERE CustomerId = 4;
Had this same issue. It looks like you're using SQLiteStudio, the latest version is 3.21 from December 2019. While your database was made in SQLite 3.30 (and your software is probably using 3.30), the version of SQLiteStudio you are using is based on 3.24.
There is an outstanding feature request to implement window functions in SQLiteStudio. Until then, the best you can do is replace the sqlite3.dll in the SQLiteStudio program directory with a newer version (3.30 , 32-bit works). Window functions will show as a syntax error, but the queries will still execute.
Related
We have an application we inherited thats on version 500+, we are not sure why its such a high version, but so be it. We have been using Flyway for a few years on it now, and have multiple releases. Sample would be it started as 500.10.4, and we are now on 500.10.20, so 16 releases containing various flyway scripts on a lot of them, but not all.
Anyway, its been determined that for simplification we are to re-version the application to 6.0.0 in the next release. Is there an easy way to let flyway know of this change, so that if we stand up another instance when it runs through the scripts it would run the 500's first, then go back to the 6's?
Currently our flyway script files are named as such:
V500.10.20_2022.05.12.0000.1__xxxx.sql and so on. So in theory our next would be
V6.0.0_2022.05.13.0000.1__xxxx.sql
I know that flyway would see version 6 as lower than 500 and ignore it. We currently have flyway out of order set to false. Is there any other options to solve this other then to set out-of-order processing to true?
In our situation we do not have any flyway scripts pre version 500. So what we are going to attempt to do is have a manual script run that will update all the data in our xxx_db_version table to be version 5.00.xxxx instead of 500.xxxx. This way when we move to 6.0, all of the scripts would be seen as next in the sequence appropriately. While the versions in this table will then not match previous actual versions of the application this table is not used for the purposes of the actual displayed version of the system or anything, and once we move to version 6, the 500 vs 5 won't really matter. and the order/sequence will still be maintained.
If this does not work, I will post a follow up.
I am trying to get the definition of table in teradata and I am using following command
show table DatabaseName.TableName;
This works fine for small tables but for large table it's not showing the full definition.
Is there any other way for this.
I am running this query on teradata sql assistant version 13.0
please help.
Your're running a quite old version of SQL Assistant and probably a quite old version of ODBC, too.
There was a bug truncating the result of a SHOW TABLE, but it was fixed years ago.
Try to get a newer release of ODBC and/or SQL Assistant (or switch to the .NET provider)
http://downloads.teradata.com/download
I've got a problem with my web application. A query that completes in a few seconds in SQLite 3.7.4 on Windows takes a whole 6 minutes in SQLite 3.6.22 on Linux. On the very same database file. It contains a few WHERE NOT EXISTS parts so I can imagine something has been optimised there.
But the SQLite version is fixed on the Linux side, it's bound to the distribution so I cannot update it. When I tried a current Linux binary and uploaded it to the server, the shell just said the file would not exist. It was there, ls found it and it was mode 755 by my own user...
And I can't find that specific version for Windows as well to try it in the other direction. The SQLite download site only contains the very current version and nothing else. There's not even an archive of older releases...
Does anybody know where I can find older versions? Preferably as binary as I don't want to spent hours to get it compiled.
You can check out and compile older releases from the Fossil repository.
I recently dug up a very old SQL Anywhere database. I have it installed and it kind of works, its only the distributed side of the data, so everything's running via dbeng50 and ODBC.
I would like to migrate this data to MySQL. Is there a way to do this? I attempted to view the data using an ODBC tool but I kept getting error messages saying the ODBC driver doesn't support the version of ODBC behavior.
I guess the database is too old (it's from 1997) - that put's at it SQL Anywhere version 5.
Its also difficult to find the old SQL tools that would help me access these.
Is it possible to use the .db file with a newer version?
Any help or guidance at all would be appreciated.
I am having problems reflecting tables in Oracle using cx_Oracle version 5.1 (autoload=True). Everything works fine under cx_Oracle version 5.0.4. Here's the error I get:
DatabaseError: (DatabaseError) ORA-01460: unimplemented or unreasonable conversion requested
Somehow, the query sent to oracle is not substituting the tablename and schema correctly. Has anybody seen anything like this and have a solution? I'd like to avoid to define columns manually for all the tables. I also want to use the latest versions if possible.
I just submitted a patch that fixes this issue for me. Support for Unicode was added to cx_Oracle and then later removed. There are a few lines in SQLAlchemy's cx_oracle.py that check the version of the cx_Oracle module. The patch updates these version checks to take into account the reverted Unicode support.
I think that it was your question that helped me get SQLAlchemy working with cx_Oracle for the first time a few weeks ago, so thanks for asking! :-D
As discussed in the thread for the patch of Alex, a solution is to set the NLS_LANG environment variable, so that cx_oracle can use the right converter. For example:
import os
os.environ["NLS_LANG"] = ".UTF8"