After upgrading TD from 2.4.0.40 to 2.6.0.32, the client prompts that it does not have the permission to insert data
Steps to reproduce the behavior:
Upgrading TDengine from 2.4.0.40 to 2.6.0.32
Write a JAVA client programto connect to TDengine
Execute the insert data statement
Screenshots
1、Table creation statement
create database db keep 36500 days 7 blocks 6 update 2;
2、Table creation statement
create stable t_point(data_time timestamp, insert_time timestamp, point_value double) tags(device_id binary(8), point_name binary(16));
3、Error message
enter image description here
OS: [e.g. CentOS 7.0]
2C 4G
TDengine Version [e.g. 2.6.0.32]
Related
I'm trying to set a connection between a PostgreSql 12 64bit on a Windows 10 (64 bit) with a MS Access 2013 (64 bit) on a windows 8.1 64bit using some of the fdw's. At this regard I:
- Set a System DSN with MSAccess 64bit driver (msdata) Unfortunately MS removed the test option for
access database connection but it seams to work.
- Using ogr_fwd I was able to set the Foreign Data Wrapper but when setting the Foreign server it refused the following options:
[dsn:msdata] (dsn not valid option),
[datasource:'Z:/database.accdb', format:'MDB'] (Unable to find MDB format idem using 'OCDB' as
format),
[datasource: 'msdata'] or [datasource:'OCDB:msdata] (unable to connect to data source xxxx)
Finally y gave up using ogr_fwd but I was able to connect to a MySQL database using it with a MySql
64 bit driver.
I tried ocdb_fdw with some more luck. Was able to create the Foreign Server; the User Mappings and two foreign tables but when I tried to run a simple query on a three records table it took for ever without showing a result ´- I tried to set the option "use_remote_estimate" on the foreign tables with the same results.
I set it up as follows:
CREATE FOREIGN DATA WRAPPER odbc_wrapper
VALIDATOR public.odbc_fdw_validator
HANDLER public.odbc_fwd_handler;
CREATE FOREIGN SERVER odbc_server
FOREIGN DATA WRAPPER odbc_wrapper
OPTIONS(dsn 'msdata');
CREATE USER MAPPING FOR PUBLIC (Ms Access database not password protected)
SERVER odbc_server;
CREATE FOREIGN TABLE public.sex
id integer NOT NULL,
sex character varying(20)[] NOT NULL
SERVER obdc_server
OPTIONS (use_remote_estimate 'True'); -- run with and without this option --
As mentioned above, the odbc_fdw allows to set it up, but I was unable of getting any return data from it.
Linking a table from Ms Access using the Ms Access MSConnector works just fine but unfortunately it only allows to link on existing PostgreSQL tables which it's not what I need. I think that somehow this
is related to the 32/64 bit mess of the Ms Access driver, but I couldn't find a workaround.
Any help would be most appreciated.
EDIT: After struggling for some time, i found out a problem with my MS Driver not related to odbc_fdw or to PostgreSQL but to windows itself. Once I fixed it, the driver ( and the DSN system data source) works just fine when tested using pyodbc.
This solve the issue of freezing (or running for a long time) but when running a query on the foreign table I got another issue that was an "ERROR: Connecting to driver SQL state: 58000 - Which stands for error outside PostgreSQL.
I tried several options at the Foreign Table such as odbc_DATABASE databasename;
schema databasename; odbc_table tablename with the same result.
I still don't have idea why ogr_fdw doesn't recognize the MsAccess 64bit driver.
This looks a bit like this case here:
PGAdmin: Not connected to the server or the connection to the server has been closed
Output of columns of type json seems not to work.
SELECT normal_column FROM table
Runs fine
SELECT * FROM table (or SELECT json_column FROM table)
Outputs: "Not connected to the server or the connection to the server has been closed."
But the notification window flashes the correct "Successfully run. N rows affected".
Did not have this problem with pgadmin 4.2 or 4.1.
This issue has been fixed
please try to test with nightly build tomorrow Ref: https://git.postgresql.org/gitweb/?p=pgadmin4.git;a=commitdiff;h=fbc6aea497c81b314e5744a24c643f369538a53d
Download: https://www.postgresql.org/ftp/pgadmin/pgadmin4/snapshots/
I'm trying to select some urdu characters from Oracle database table on linux shell on red hat server but it is displaying as "??????". Below is the output on shell
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL> select * from urdu_test;
MSISDN
CUSTOMER_NAME
923165106151
???? ???? ??? ???? ?? ?? ??? ?? ???? ???
on DB side below are the characterset parameters.
on red hat server i export the NLS_LANG variable as below
export NLS_LANG=AMERICAN_AMERICA.UTF
But i'm still unable to select the urdu characters from db. On DB side i can insert and select the characters manually.
Any support will be appreciated, what variables need to be check on linux side?
This statement returns null instead of 64 random bytes:
select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
What is causing it to return null? Database is Oracle 10.1.0.2.0 running on Windows Server 2003 and I want to use the random bytes as salt for password hashing.
Edit: Here's the output from sqlplus:
Connected to:
Oracle Database 10g Release 10.1.0.2.0 - Production
SQL> select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
DBMS_CRYPTO.RANDOMBYTES(64)
--------------------------------------------------------------------------------
SQL>
Edit2: When switching to Oracle 11 the query works. I have no idea why it doesn't work on Oracle 10 but have decided to not use that old database.
It works perfectly. I have tested it on Oracle 12c.
Update
I have checked My Oracle Support(Metalink), however, did not find anything related to this function returning NULL. Certainly, not a bug.
Anyway, looking deeper into the function and it's usage in the documentation, I came across SQLNET.CRYPTO_SEED
SQLNET.CRYPTO_SEED
Purpose
Use the parameter SQLNET.CRYPTO_SEED to specify the characters used
when generating cryptographic keys. The more random the characters
are, the stronger the keys are. The string should be 10-70 random
characters. This optional parameter is required for when encryption or
checksumming are turned on. Encryption is turned on if the
SQLNET.ENCRYPTION_CLIENT parameter is specified for the client and the
SQLNET.ENCRYPTION_SERVER parameter is specified for the database
server; checksumming is turned on if the SQLNET.CRYPTO_CHECKSUM_CLIENT
parameter is specified for the client and the
SQLNET.CRYPTO_CHECKSUM_SERVER parameter is specified for the database
server.
It might be possible that the parameter is not properly set in your environment. I don't have 10g version(obsolete though) to test.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing option
SQL> select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
DBMS_CRYPTO.RANDOMBYTES(64)
--------------------------------------------------------------------------------
427AECD44D27CDF6CDC8F290D9F8079109BAB8AECD7E687E7ADF8E15825BBDF3D746FBC181059443
965B1425B224CC46E8CD07CC2D02B2E023238E8883520A19
SQL>
I got this error when trying to run a query in SQL server query analyzer.
What is the reason?
If you're using cursors, then you've probably closed the cursor. Check out MSDN for more information (http://support.microsoft.com/kb/151693)
If you're not using cursors, then it could be an issue with the server, check the log.
And before it's lost to the sands of time, the KB article:
Article ID: 151693 - Last Review: October 3, 2003 - Revision: 3.0
FIX: Err Msg "Unknown Token Received from SQL Server"
Symptoms
When you set the statement options to use a server-side cursor and prepare a select statement on a SQL Server system table, the first execution of the select creates the cursor successfully. After you close this cursor, if you execute the prepared statement again, the following error message appears:
unknown token received from SQL Server.
Workaround
Use a forward-only cursor instead of a static, keyset, or dynamic cursor on the system tables. Note that the problem does not occur if a server-side cursor is created on a user-defined table or view.
If a forward-only cursor is unacceptable, prepare the select statement again on the system table and execute it to create a server-side cursor. Note that the first execution works fine and applications typically do not need to create a cursor on a system table repeatedly.
Status
Microsoft has confirmed this to be a problem in Microsoft SQL Server version 6.50.0201. This problem has been corrected in U.S. Service Pack 1 for Microsoft SQL Server version 6.5. For more information, contact your primary support provider.