When I type the following command on the SQL editor I get Error Code: 1064
EDIT my_database.my_table;
but the commands
SELECT * from my_database.my_table;
works fine.
Thanks
The EDIT command was only a temporary workaround until we had proper parsing in place to determine if a query result can be edited or not. This keyword is no longer supported since a year or more.
Related
When I launch my query into pgAdmin 4 v5's Query Tool I get this type of data representation (this is also what I would like to get in my export file).
Unfortunately this information is transformed when saving it to a .TXT file by clicking the following button and saving it as indicated in the subsequent image.
As you can see below, after double-clicking on the saved TXT document, it added '.0' and wrapped my long character by indicating 'e+29' up to a certain row.
Can you please indicate me how to remove those transformations ?
All,
I found out the above problem is linked with the version of pgAdmin I was using, pgAdmin 4 v5 precisely.
After downloading pgAdmin 4 v6.4 the problem doesn't appear anymore.
I consider this thus as fixed, even if the cause of the problem remains unknown to me.
Thanks for your help.
Brieuc
I'm trying to use the SQL script action. My statements are separated by ; and a new line. Simply using ; as the statement delimiter is the best luck I've had, but unfortunately some of my statements have ; in the values and it breaks on those. I've tried using
;$
;\n
\);
but it keeps trying to execute the whole script as a single statement. I can't figure out where i'm going wrong here.
I'm using version 8.0.3
This is indeed a bug that will be fixed in 8.0.5. Both ;$ and ;\n will work in 8.0.5. To get a build where this is already fixed, please contact support#ej-technologies.com.
UPDATE: in the workbench/J log file I am seeing this error:
ERROR Variable names may only contain characters (a-z, A-Z), numbers and underscores
I'm sure this is what is causing my process to fail, but I have no idea why because my variables are named appropriately. I've tried renaming them a few times just in case and the same thing happens.
ORIGINAL POST:
I am working on an automated process to dump the contents of a Postgres query to a text file and FTP it to someone. The process I have been using successfully is a windows batch script that runs SQL Workbench to run the query and write the entire contents of the table to a text file and FTP it.
Now I want to be able to use WBVarDef to load a variable from a text file and use it in my query. For reference, the variable is the unique id of the last record that was FTPed. This is the code i have:
WBVarDef -variable=id -contentFile=id.txt;
WBVardef today=#"select to_char(current_date,'mmddyyyy')";
WBExport -type=text
-file='c:/CLP/FTP/$[today]circ_trans.txt'
-delimiter='|'
-quoteAlways=true
-lineEnding=crlf
-encoding=utf8;
SELECT
*
FROM
transactions
WHERE
transactions.id > $[id]
ORDER BY
transactions.id;
The only thing new here is the reference to the text file that contains the id on the first line. This completely breaks the process but as far as I can tell, I am using this according to the SQL Workbench documentation.
Any help would be greatly appreciated.
I have figured this one out. I was running an older version of workbench that did not support this functionality. Now that I upgraded to build 119 this is working. I'm having other issues but that's a different story....
I'm attempting to output a table to an outside file. I've found a few questions regarding this and followed the answers from there without any luck.
SELECT *
FROM transactions;
OUTPUT TO 'C:\Users\administrator\Desktop\Test.txt'
Is the statement I've been using, I've attempted different variations with formatting and file types such as .csv with no change.
Which produces:
ErrorCode : 102
SQLState : 42W04
Message : SQL Anywhere Error -131: Syntax error near 'OUTPUT' on line 1
SQL =
OUTPUT TO 'C:\Users\administrator\Desktop\Test.txt'
Appreciate all your help
Are you running this through dbisql, or in a different application? OUTPUT TO is a dbisql command, not a SQL statement recognized by the database server. You can use the UNLOAD statement in any application to allow the server to create the file.
Disclaimer: I work for SAP in SQL Anywhere engineering.
This is my sql statement
IF EXISTS (select 1 from sysobjects where name = 'PNL_VALUE_ESTIMATE')
drop table dbo.PNL_VALUE_ESTIMATE
go
isql bails out with this error message
Msg 102, Level 15, State 1:
Server 'DB_SERVER', Line 3:
Incorrect syntax near 'go'.
But the sql statement look correct to me. What's wrong?
Sybase version is 15
Try this:
IF EXISTS (select 1 from sysobjects where name = 'PNL_VALUE_ESTIMATE')
drop table dbo.PNL_VALUE_ESTIMATE
go
or this:
IF EXISTS (select 1 from sysobjects where name = 'PNL_VALUE_ESTIMATE')
BEGIN
drop table dbo.PNL_VALUE_ESTIMATE
END
go
or this:
IF EXISTS (select 1 from sysobjects where name = 'PNL_VALUE_ESTIMATE')
BEGIN
select 1
END
go
Does any work?
GO is not a keyword of T-SQL, but of the editor.
SMSS (between others) uses it as 'division' between batches of commands it sends to the database server. Executing it inside a stored procedure, or even a script file, won't work.
edit: Maybe it works with SyBase, but I think it'll need to be uppercase in that case.
From the documentation, the GO statement is a command of the editor you're using, not SQL itself:
GO is not a Transact-SQL statement; it is a command recognized by the
sqlcmd and osql utilities and SQL Server Management Studio Code
editor.
That said - Sybase is also an editor that supports the GO statement.
I've had the same problem, but with SQL Management Studio. The issue is that the editor does not support mixed-newline types around certain statements - GO being one of them. In Management Studio, for example, only Windows-style newlines (CR + LF) are allowed and if I were to use the Linux format (LF), it will give the exact same error as yours above.
Text-editors such as Notepad++ (what I use) have an option for what type of End-of-Line characters you use by default (Windows, Linux, Mac (CR)).
Try checking what newline character(s) are being used in your statements to see if that can fix the problem.
Shouldn't the object reference have
dbo..PNL_VALUE_ESTIMATE
because you haven't given a database name, and if you include the obj owner you need .. to miss the db name?
I'd go:
EXEC('DROP TABLE dbo..PNL_VALUE_ESTIMATE')
in the true part as well, because DROP TABLE is always compiled, and if the table isn't there you'll still have a failure.
Do you even need dbo? If your sql always runs as dbo just leave it out.