I keep getting a message whenever I insert or update any record in any table in my database:
[34931.406] SQL_Statement 1 4 -1 999999999 01S02 -5 -- cursor updatability changed
I was wondering exactly what this message means and why I am getting it. Is it safe to ignore?
Am I supposed to react to it / do something different?
Thanks for reading
Just in case its necessary -
I'm running PostgreSQL 9.1.2 on Ubuntu LTE
I'm using 32bit ODBC psqlodbc_09_01_0100 on Windows 7 x64
I'm also using a third party odbc library "SQLTools" by PerfectSync - but I don't think thats making the message because I also use it with MySQL with no problems
Are u updating cursor's elements directly?
in this case warning message is informing u that u are changin' cursor's elements while it's open.
Something similar happens, in java language when tryng to change list's elements number (adding or removing elements) while iterating it.
Related
I run into a Cannot enlarge string buffer message on my running postgREST API. I guess some tables are too large to work successful with the API.
I am using the docker postgrest/postgrest container from https://hub.docker.com/r/postgrest/postgrest with the version PostgREST 5.1.0.
Everything is working as expected but if the tables size getting too large, I get following error message.
hint null
details "Cannot enlarge string buffer containing 1073741822 bytes by 1 more bytes."
code "54000"
message "out of memory"
I can't determine the threshold when it's working or not.
Is there a possibility to enlarge the string buffer in some config file or is this hardcoded?
Are there any limits from the table size working with the API. So far I couldn’t find any information in the docu.
=========== Update
The postgres logs give me following SQL query:
WITH pg_source AS (
SELECT "public"."n_osm_bawue_line".*
FROM "public"."n_osm_bawue_line"
)
SELECT null AS total_result_set,
pg_catalog.count(_postgrest_t) AS page_total,
array[]::text[] AS header,
coalesce(json_agg(_postgrest_t), '[]')::character varying AS body
FROM (
SELECT *
FROM pg_source
) _postgrest_t
I use following postgres version:
"PostgreSQL 11.1 (Debian 11.1-1.pgdg90+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit"
Unless you recompile PostgreSQL is not possible to upgrade the limit(defined here).
My suggestion would be to try to reduce the size of the payload(are you sure you need all the data?) or get all of the payload in multiple requests.
With PostgREST you can do vertical filtering(just select the columns that you need) or paginate to reduce the number of rows you get in one request.
The error message comes from PostgreSQL. PostgREST just wraps the message in JSON and sends the HTTP response.
As a first step for finding the problem, look what is the exact HTTP request you do to trigger the error.
Then, enable PostgreSQL logging and repeat the request, check the logs and then you'll see what is the SQL query that causes this error. Run the query through pgAdmin or psql to make sure you got the problematic query.
Update your question with your findings. The SQL query would be what is needed to continue.
After that you could add a postgresql tag to your question.
There is always the possibility that the file being imported is either corrupted or malformed because of any number of reasons.
I just happened to have discovered in my case that my file had something like incorrect line endings (long story, unnecessary here) which caused the whole file to appear as one line, thus causing the obvious result. You may have something similar in your case that requires a find+replace kind of solution.
For whatever benefit to anyone else, I used this to resolve it:
tr -d '\0' < bad_file.csv > bad_file.csv.fixed
I am running into an issue where if I have more than 15 LIKE operators within a case statement, I get an error java.lang.StackOverflowError.
Here is an example of what I am doing against a table with 60 million rows:
SELECT
CASE WHEN field LIKE '%value%' THEN 'result'
WHEN field LIKE '%value2%' THEN 'result2'
.... 14 more of those
END
I haven't seen this limitation documented anywhere. Any ideas how to get around this?
It sounds like it's an out-of-memory error.
I think you have some options:
use an intermediate table before doing the like processing (or use intermediate tables to process subsets of your initial data)
bump up the number of queue slots that you're using for this query to have more memory available https://docs.aws.amazon.com/redshift/latest/dg/r_wlm_query_slot_count.html
take a look at the explain output to see if it gives you clues about what's going wrong
You could Create a Scalar Python User-Defined Function to replace the LIKE comparisons.
Then, just use:
SELECT f_myfunc(field)
This turned out to be a driver issue. I was initially using 1.2.16.1027 and upgraded to 1.2.20.1043 and I am no longer receiving the error.
I want to drop a column called id which is an auto incrementing PK.
The SQL:
alter table "CO88GT"."XGLCTL" drop column id cascade;
And I get:
Error: [SQL0952] Processing of the SQL statement ended. Reason code 10.
SQLState: 57014
ErrorCode: -952
I could be wrong but I think it has something to do with preventing the table from losing data. To get around this issue I need to create a new table without the column and copy the data from the old table into the new table and then replace the old table with the new table.
Info
AS400 is giving you a warning (inquiry message) because of possible data loss, asking you to Cancel or Ignore the requested operation. So, beacuse of this being a interactive request, over JDBC/ODBC you cannot type 'I' to ignore, and AS throws you an ErrorCode: -952 with SQLState: 57014 and Reason code 10.
In the documentation of SQL0952 says:
Message Text: Processing of the SQL statement ended. Reason code &1.
Cause Text: The SQL operation was ended before normal completion. The reason code is &1. Reason codes and their meanings are:
* 1 - An SQLCancel API request has been processed, for example from ODBC.
* 2 - SQL processing was ended by sending an exception.
* 3 - Abnormal termination.
* 4 - Activation group termination.
* 5 - Reclaim activation group or reclaim resources.
* 6 - Process termination.
* 7 - An EXIT function was called.
* 8 - Unhandled exception.
* 9 - A Long Jump was processed.
* 10 - A cancel reply to an inquiry message was received.
* 11 - Open Database File Exit Program (QIBM_QDB_OPEN).
* 0 - Unknown cause.
If you are using JDBC and the SQL error isn't self-explanatory, you can make a JDBC connection with parameter 'errors=full', which will give much more info on the error. For other connection parameters see this.
example connection string:
jdbc:as400://serverName;libraries=*libl;naming=system;errors=full;
With that connection the resulting error would be like this:
Error: [SQL0952] Processing of the SQL statement ended. Reason code 10.
Cause . . . . . : The SQL operation was ended before normal completion.
The reason code is 10.
Reason codes and their meanings are:
1 -- An SQLCancel API request has been processed, for example from ODBC.
2 -- SQL processing was ended by sending an exception.
3 -- Abnormal termination.
4 -- Activation group termination.
5 -- Reclaim activation group or reclaim resources.
6 -- Process termination.
7 -- An EXIT function was called.
8 -- Unhandled exception.
9 -- A Long Jump was processed.
10 -- A cancel reply to an inquiry message was received.
11 -- Open Database File Exit Program (QIBM_QDB_OPEN).
0 -- Unknown cause.
Recovery . . . : If the reason code is 1, a client request was made to cancel SQL processing. For all other reason codes, see previous messages to determine why SQL processing was ended.
SQLState: 57014
ErrorCode: -952
The solution
So finally, if you cannot use STRSQL, another solution is to use iSeries Navigator, to be exact its "Run SQL scripts" (it is usually here --> "%Program Files%\IBM\Client Access\Shared\cwbundbs.exe").
But first of all you have to add a system reply parameter (only once per machine)
ADDRPYLE SEQNBR(1500) MSGID(CPA32B2) RPY('I')
This is done in "green screen". This sets a deafult answer ('I') on CPA32B2 inquiry message. The CPA32B2 is an internal massage id, which is tied to an drop column operation.
(It actually doesn't have to be done in "green screen", use it like CHGJOB command. Example :
cl: ADDRPYLE SEQNBR(1500) MSGID(CPA32B2) RPY('I');
)
Now you can start "Run SQL scripts", the first command to run is:
cl: CHGJOB INQMSGRPY(*SYSRPYL);
this changes the current job parameter INQMSGRPY, to *SYSRPYL. *SYSRPYL causes to look if exists a system reply parameter when an inquiry message should be displayed.
Now you can run your alter which drops the column.
Unfortunately, I don't know how to drop a column, just using JDBC. If someone knows please let me know.
References:
Understanding What Controls the Automatic Reply Function
Replying to Run-Time Inquiry Messages
Error in dropping column (forum post)
How can I avoid SQL0952 on ALTER TABLE?
Finally I found a solution:
CALL QSYS2.QCMDEXC('ADDRPYLE SEQNBR(1500) MSGID(CPA32B2) RPY(''I'')');
CALL QSYS2.QCMDEXC('CHGJOB INQMSGRPY(*SYSRPYL)');
ALTER TABLE <tablename> DROP COLUMN <column_name>;
There isn't enough information in your error message to be sure, but dropping a primary key column is generally quite risky and the database correctly makes it difficult.
You likely have a foreign key constraint involving that column.
Don't drop the constraint and delete that column unless you're sure you know what you're doing.
According to this post: http://bytes.com/topic/db2/answers/185467-drop-column-table
It is possible to drop a column using STRSQL in the green screen environment. I have access to this and it does work, but a client with a 400 does not have the licensed program to use STRSQL. The issue is that STRSQL will prompt if this is something I really want to do.
To get at the data I'm using SQuirrel SQL client with the JT400 JDBC driver... So I guess with the system insisting on prompting (and actually no way of getting the prompt even without STRSQL) it won't let me do it.
So I guess I'm stuck doing what I'm doing... creating a new table and copying the data and then swapping the tables.
The only way I found to get jdbc to work is to first manually change the default for this message. Then run your update application. In our case we use Liquibase. I could get the java's CommandCall to call ADDRPYLE and CHGJOB INQMSGRPY(*SYSRPYL), but it never actually allowed the alter table * drop column * to not give the follow error:
Error:
10 -- A cancel reply to an inquiry message was received.
Working Command:
CHGMSGD MSGID(CPA32B2) MSGF(QSYS/QCPFMSG) DFT('I')
Reference:
http://knowledgebase.progress.com/articles/Article/9678
green screen -- STRSQL will give you error msg to answer
alter table devlibsc/trklst drop column "ST"
Change of file TRKLST may cause data to be lost. (C I)
I have read and read over MSDN, etc. Ok, so it signals the end of a batch.
What defines a batch? I don't see why I need go when I'm pasting in a bunch of scripts to be run all at the same time.
I've never understood GO. Can anyone explain this better and when I need to use it (after how many or what type of transactions)?
For example why would I need GO after each update here:
UPDATE [Country]
SET [CountryCode] = 'IL'
WHERE code = 'IL'
GO
UPDATE [Country]
SET [CountryCode] = 'PT'
WHERE code = 'PT'
GO is not properly a TSQL command.
Instead it's a command to the specific client program which connects to an SQL server (Sybase or Microsoft's - not sure about what Oracle does), signalling to the client program that the set of commands that were input into it up till the "go" need to be sent to the server to be executed.
Why/when do you need it?
GO in MS SQL server has a "count" parameter - so you can use it as a "repeat N times" shortcut.
Extremely large updates might fill up the SQL server's log. To avoid that, they might need to be separated into smaller batches via go.
In your example, if updating for a set of country codes has such a volume that it will run out of log space, the solution is to separate each country code into a separate transaction - which can be done by separating them on the client with go.
Some SQL statements MUST be separated by GO from the following ones in order to work.
For example, you can't drop a table and re-create the same-named table in a single transaction, at least in Sybase (ditto for creating procedures/triggers):
> drop table tempdb.guest.x1
> create table tempdb.guest.x1 (a int)
> go
Msg 2714, Level 16, State 1
Server 'SYBDEV', Line 2
There is already an object named 'x1' in the database.
> drop table tempdb.guest.x1
> go
> create table tempdb.guest.x1 (a int)
> go
>
GO is not a statement, it's a batch separator.
The blocks separated by GO are sent by the client to the server for processing and the client waits for their results.
For instance, if you write
DELETE FROM a
DELETE FROM b
DELETE FROM c
, this will be sent to the server as a single 3-line query.
If you write
DELETE FROM a
GO
DELETE FROM b
GO
DELETE FROM c
, this will be sent to the server as 3 one-line queries.
GO itself does not go to the server (no pun intended). It's a pure client-side reserved word and is only recognized by SSMS and osql.
If you will use a custom query tool to send it over the connection, the server won't even recognize it and issue an error.
Many command need to be in their own batch, like CREATE PROCEDURE
Or, if you add a column to a table, then it should be in its own batch.
If you try to SELECT the new column in the same batch it fails because at parse/compile time the column does not exist.
GO is used by the SQL tools to work this out from one script: it is not a SQL keyword and is not recognised by the engine.
These are 2 concrete examples of day to day usage of batches.
Edit: In your example, you don't need GO...
Edit 2, example. You can't drop, create and permission in one batch... not least, where is the end of the stored procedure?
IF OBJECT_ID ('dbo.uspDoStuff') IS NOT NULL
DROP PROCEDURE dbo.uspDoStuff
GO
CREATE PROCEDURE dbo.uspDoStuff
AS
SELECT Something From ATable
GO
GRANT EXECUTE ON dbo.uspDoStuff TO RoleSomeOne
GO
Sometimes there is a need to execute the same command or set of commands over and over again. This may be to insert or update test data or it may be to put a load on your server for performance testing. Whatever the need the easiest way to do this is to setup a while loop and execute your code, but in SQL 2005 there is an even easier way to do this.
Let's say you want to create a test table and load it with 1000 records. You could issue the following command and it will run the same command 1000 times:
CREATE TABLE dbo.TEST (ID INT IDENTITY (1,1), ROWID uniqueidentifier)
GO
INSERT INTO dbo.TEST (ROWID) VALUES (NEWID())
GO 1000
source:
http://www.mssqltips.com/tip.asp?tip=1216
Other than that it marks the "end" of an SQL block (e.g. in a stored procedure)... Meaning you're on a "clean" state again... e.G: Parameters used in the statement before the code are reset (not defined anymore)
As everyone already said, "GO" is not part of T-SQL. "GO" is a batch separator in SSMS, a client application used to submit queries to the database. This means that declared variables and table variables will not persist from code before the "GO" to code following it.
In fact, GO is simply the default word used by SSMS. This can be changed in the options if you want. For a bit of fun, change the option on someone else's system to use "SELECT" as a batch seperator instead of "GO". Forgive my cruel chuckle.
It is used to split logical blocks. Your code is interpreted into sql command line and this indicate next block of code.
But it could be used as recursive statement with specific number.
Try:
exec sp_who2
go 2
Some statement have to be delimited by GO:
use DB
create view thisViewCreationWillFail
I have error "Cocoa error 256" when I try to save data. How to fix it? And what problem?
According to the help reference in Xcode:
NSFileReadUnknownError
Read error, reason unknown
Available in Mac OS X v10.4 and later.
Declared in FoundationErrors.h.
Sadly, that's probably not too helpful, though it is an unknown -read- error.
If its a core data error there is probably an actual error object somewhere near where the error occurs. If you dump the error objects userInfo dictionary, you can usually get a lot more detail than just the error code itself.
This is what it boils down to (as Tegeril said)
NSFileReadUnknownError Read error,
reason unknown
Available in Mac OS X v10.4 and later.
Declared in FoundationErrors.h.
A file can also be a resource located at a URL/URI, if the URL has unencoded characters it can cause this type of error.
Check the path to the resource/file.
I ran into exactly this error when populating an SQLite database for an iOS app using a custom script (ie not using Core Data). It turns out that there is some metadata which you have to update yourself, after adding new rows. Find the row in Z_PRIMARYKEY where Z_NAME equals the name of the table you've just inserted into. Make sure that Z_MAX in this row is equal to the highest value of Z_PK in the table you've inserted the rows into. In my case, as soon as I updated Z_MAX with the correct number, the error went away.
So, for the "ZAUTHOR" table:
SELECT z_pk FROM ZAUTHOR ORDER BY z_pk DESC LIMIT 1; /* Returns 1234 */
UPDATE Z_PRIMARYKEY SET z_max = 1234 WHERE z_name = 'Author';
This is the article which helped me track down the error.
I get this error on Xcode 6 (& 7) when switching a network connection while the Simulator is open. For example moving from one wireless network to another. The solution for me is to Quit Simulator and restart.