USE XXX
go
CREATE GLOBAL TEMPORARY TABLE #dbo.tbl_gbl_temp11
(parent_deal_id numeric(10,0) not null,
deal_id numeric(10,0) not null,
code_name varchar(100) null
)
go
IF OBJECT_ID('dbo.tbl_gbl_temp1') IS NOT NULL
PRINT '<<< CREATED TABLE dbo.tbl_gbl_temp1 >>>'
ELSE
PRINT '<<< FAILED CREATING TABLE dbo.tbl_gbl_temp1 >>>'
go
When I execute the above it gives the following error:
Number (156) Severity (15) State (2) Server (XXX) Incorrect syntax near the keyword 'TABLE'.
CREATE GLOBAL TEMPORARY TABLE is supported in ASE 16.0 SP02.
There is no CREATE GLOBAL TEMPORARY TABLE command in Sybase ASE.
SAP ASE version 16.0 SP2 supports CREATE GLOBAL TEMPORARY TABLE
For temp tables use the standard create table syntax, with local temp tables prefixed with a # or global temp tables by specifying tempdb..tbl_name
So in your case it would be
USE XXX
go
CREATE TABLE tempdb..tbl_gbl_temp11 //if the owner is dbo it does not need to be listed.
(parent_deal_id numeric(10,0) not null,
deal_id numeric(10,0) not null,
code_name varchar(100) null
)
go
IF OBJECT_ID('tempdb..tbl_gbl_temp1') IS NOT NULL
PRINT '<<< CREATED TABLE dbo.tbl_gbl_temp1 >>>'
ELSE
PRINT '<<< FAILED CREATING TABLE tempdb..tbl_gbl_temp1 >>>'
go
Sybase ASE Transact SQL Reference Guide: Temporary Tables
The data will be shared between processes, so you may need to add a spid or other identifier to ensure you don't truncate another processes data when you clean up user/session data.
Related
It seems like a bug in Version 19.4 which is fixed in 20+
I exported the content of my tables in sqldeveloper and the insert sql statements all have number as strings.
Example:
Insert into testtable(id,stuff) values ('1','Hello')
ID 1 becomes '1' in the export and I have trouble reading it in.
This is the case for every table. Is there a way to avoid the two ' ?
The DDL is:
create table TESTTABLE(
ID INTEGER not null
);
after executing its this in sqldeveloepr:
create table testtable{
"ID" Number(*,0) NOT NULL ENABLE
}
I noticed that I'm able to add such a line, if the constraints are not active. It seems like sqldeveloper convertes the string to a number internally.
create table testtable(
"ID" Number(*,0) NOT NULL ENABLE
);
insert into testtable values (1);
commit;
select /*insert*/ * from testtable;
Running this, i get
Table TESTTABLE created.
1 row inserted.
Commit complete.
REM INSERTING into TESTTABLE
SET DEFINE OFF;
Insert into TESTTABLE (ID) values (1);
No quotes on the number value/field. I did this with version 20.2 of SQL Developer.
I have created the following setup script. The script is meant to be run before the application (which would run on node) is deployed.
The idea is that it would eventually contain all table definitions, relations, stored procedures and some seed data to make the application work, split into different files.
But currently I'm stuck because I can't figure out how I can store data in variables.
In this example we have profiles (because user is a keyword) and inventories. I want each user to have an inventory. For this to work I need to generate an inventory, store its id in a variable and pass it to the profile.
But for some reason postgres won't allow me to declare variables. Heres what I got so far:
drop database test;
create database test;
\c test
create extension if not exists "uuid-ossp";
create table inventory(
id uuid PRIMARY KEY DEFAULT uuid_generate_v4(),
name text
);
create table profile(
id uuid PRIMARY KEY DEFAULT uuid_generate_v4(),
name text,
inventory_id uuid references inventory(id)
);
DECLARE myid uuid;
/*I want to set the inv_id to the result of this expression*/
insert into inventory(name) values('asdf') returning id into myid;
insert into profile(name,inventory_id) values ('user1',#myid)
But I get the following error:
$ psql -U postgres -f init.sql
psql:init.sql:18: ERROR: syntax error at or near "uuid"
LINE 1: DECLARE myid uuid;
^
So how can I create a variable to store this id? Am I doing something wrong in general, because I'm pretty sure Declare is part of the SQL spec.
You can use
WITH myids AS (
INSERT INTO inventory(name)
VALUES ('asdf')
RETURNING id
)
INSERT INTO profile(name,inventory_id)
SELECT 'user1', id
FROM myids;
Postgresql lost the autoincrement feature after a restore. My database was created on Windows 10 (v 10.1) and I restored it to Postgresql on Ubuntu (v 9.6). Now that I posted the question I saw that the versions are different. I didn't use any obscure feature, only tables, functions, and columns with serials. Also, the restore process didn't complain about anything. I checked the dump options but I couldn't find anything that caused the problem.
With Pgadmin right-clicking the table > scripts > create a script on my original table gives this:
CREATE TABLE public.produto
(
produto_id integer NOT NULL DEFAULT nextval('produto_produto_id_seq'::regclass),
...
);
In my server, the restored database. It seems it lost the feature.
CREATE TABLE public.produto
(
produto_id integer NOT NULL,
...
);
You didn't check for errors during restore of the database; there should have been a few.
A dump of a table like yours will look like this in PostgreSQL v10 (this is 10.3 and it looks slightly different in 10.1, but that's irrelevant to this case):
CREATE TABLE public.produto (
produto_id integer NOT NULL
);
ALTER TABLE public.produto OWNER TO laurenz;
CREATE SEQUENCE public.produto_produto_id_seq
AS integer
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE public.produto_produto_id_seq OWNER TO laurenz;
ALTER SEQUENCE public.produto_produto_id_seq
OWNED BY public.produto.produto_id;
ALTER TABLE ONLY public.produto
ALTER COLUMN produto_id
SET DEFAULT nextval('public.produto_produto_id_seq'::regclass);
Now the problem is that AS integer was introduced to CREATE SEQUENCE in PostgreSQL v10, so that statement will fail with a syntax error in 9.6.
What is the consequence?
The table is created like in the first statement.
The third statement creating the sequence fails.
All the following statements that require the sequence will also fail.
Note: It is not supported to downgrade PostgeSQL with dump and restore.
The solution is to manually edit the dump until it works, in particular you'll have to remove the AS integer or AS bigint clause in CREATE SEQUENCE.
The create table query is as followed.
CREATE TABLE xxx (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL,
name VARCHAR(255) NOT NULL,
created DATE
);
it returns :
Table xxx created
Execution time: 0.11s
If I now try to select then I get:
SELECT * FROM xxx;
ERROR: relation "xxx" does not exist
Position: 15
If I try to recreate table I get
ERROR: relation "xxx" already exists
1 statement failed.
Execution time: 0.12s
And to top it off. If I reconnect. Then I can do it all over again.
I am using SQL Workbench to connect to the database on AWS RDS.
I am using the master account for these queries.
Can you use PgAdmin to see if it helps. I have my Postgres RDS configured with PgAdmin and haven't faced this issue
Okay I found the problem and in retro spec it makes a lot of sense. The problem was
that I was not committing the changes to database. I guess as I have never worked in a non auto commit environment then I did not know to look for this. Butting the create statement between begin and end like so:
BEGIN;
CREATE TABLE xxx (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL,
name VARCHAR(255) NOT NULL,
created DATE
);
END;
worked
Postgresql lost the autoincrement feature after a restore. My database was created on Windows 10 (v 10.1) and I restored it to Postgresql on Ubuntu (v 9.6). Now that I posted the question I saw that the versions are different. I didn't use any obscure feature, only tables, functions, and columns with serials. Also, the restore process didn't complain about anything. I checked the dump options but I couldn't find anything that caused the problem.
With Pgadmin right-clicking the table > scripts > create a script on my original table gives this:
CREATE TABLE public.produto
(
produto_id integer NOT NULL DEFAULT nextval('produto_produto_id_seq'::regclass),
...
);
In my server, the restored database. It seems it lost the feature.
CREATE TABLE public.produto
(
produto_id integer NOT NULL,
...
);
You didn't check for errors during restore of the database; there should have been a few.
A dump of a table like yours will look like this in PostgreSQL v10 (this is 10.3 and it looks slightly different in 10.1, but that's irrelevant to this case):
CREATE TABLE public.produto (
produto_id integer NOT NULL
);
ALTER TABLE public.produto OWNER TO laurenz;
CREATE SEQUENCE public.produto_produto_id_seq
AS integer
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER TABLE public.produto_produto_id_seq OWNER TO laurenz;
ALTER SEQUENCE public.produto_produto_id_seq
OWNED BY public.produto.produto_id;
ALTER TABLE ONLY public.produto
ALTER COLUMN produto_id
SET DEFAULT nextval('public.produto_produto_id_seq'::regclass);
Now the problem is that AS integer was introduced to CREATE SEQUENCE in PostgreSQL v10, so that statement will fail with a syntax error in 9.6.
What is the consequence?
The table is created like in the first statement.
The third statement creating the sequence fails.
All the following statements that require the sequence will also fail.
Note: It is not supported to downgrade PostgeSQL with dump and restore.
The solution is to manually edit the dump until it works, in particular you'll have to remove the AS integer or AS bigint clause in CREATE SEQUENCE.