I run the following query against Teradata using SAS, and it works fine
SELECT LEFT(first_name,7)
FROM testTab
However, when I run the same query in Sql Assistant it throws an error : Expected something between keyword SELECT and keyword LEFT.
On my other computer, the above code runs on Sql Assistant.
So, my question is, why does the LEFT function work sometimes, and sometimes it doesn't ?
There are a lot of workarounds, but I want to know what the hell is going on with this LEFT function ?
I'm not sure how the SAS version was running as LEFT is not a function in Teradata. LEFT is a keyword in Teradata because of LEFT OUTER JOIN. Perhaps SAS has some sort of parser/rewrite thing that changes it over to proper Teradata function.
At any rate, to do this in Teradata you can do:
SELECT SUBSTRING(first_name FROM 1 FOR 7) FROM testtab
Workaround:
SELECT { fn LEFT(first_name,7) } FROM testTab;
Note: This needs to be run from SQL Assistant with ODBC connection with following special settings:
In SQL Assistant go to Tools --> "Define ODBC Data Source" --> << Click on desired Teradata DNS >> --> Configure --> Options --> "Enable Legacy Parser"
To resolve, go to configure OBDC -> Options -> check "Enable Legacy Parsing"
Or you can write in SEL { fn FunctionName() };
e.g. SEL {fn MONTH(DATE) };
Related
I've just written following erroneous ABL query:
FOR EACH T1 (WHERE T1.some-date = ' ') AND
(integer(T1.num1) >= 100) AND
(integer(T1.num1) <= 200) AND
(T1.some-other-date = 01/12/2021) AND
(T2.Name = itsme),
EACH T2 WHERE T2.num2 = T1.num2
BY T1.num1
As you can see, this is wrong because I've put the first bracket in front of "WHERE" instead of behind it. In top of that, my name "itsme", is not put between quotes, so the ABL query will never work.
I've been looking in my development environment ("Tools" menu), but I couldn't find an ABL query tester. I've also checked the directory "C:\Progressx86\OpenEdge\bin", but being a newbie I didn't find anything.
I have downloaded the "DataDigger" application, which contains a so-called "MCF Query Tester", but this only works on single table and only checks criteria, not entire ABL queries.
Does anybody know where I can find an ABL query tester, first for syntax checking (the bracket in front of the "WHERE") and (if possible) for data testing (01/12/2021, is that January 12th or December 1st?)?
Thanks in advance
Dominique
Create a new OpenEdge project in Progress Developer Studio for Openedge. Create a new ABL procedure under the project with the necessary database connection. Copy the above ABL code into the procedure file and you should be able to see the errors and warnings in your procedure file.
The ABL Scratch Pad view of Progress Developer Studio allows to execute ad-hoc queries.
https://knowledgebase.progress.com/articles/Knowledge/000055088
You don't mention which editor you're using, but in general terms, the ABL COMPILE statement performs syntax checking. There's no separate/independent executable that compiles/checks syntax. Generally you'll need to write a .P to perform the compilation.
You can use the PCTCompile Ant task if you'd like to use an Ant- or Gradle-based build system.
As to date formats, I thought that was in the doc, but no. Dates always have a MM/DD/YYYY format when hard-coded; decimals always use a . decimal separator (ie 123.45) when hard-coded.
Another way to test a query you're working on would be to use query-prepare which accepts a string.
DEFINE QUERY q-Test FOR T1, T2.
QUERY q-test:HANDLE:QUERY-PREPARE("your query string here").
One of my colleagues showed me an incredible easy solution:
Copy the query in a separate procedure window and add the results you want to see, something like this:
FOR EACH T1 (WHERE T1.some-date = ' ') AND
(integer(T1.num1) >= 100) AND
(integer(T1.num1) <= 200) AND
(T1.some-other-date = 01/12/2021) AND
(T2.Name = itsme),
EACH T2 WHERE T2.num2 = T1.num2
BY T1.num1
/* To be added for viewing results */
DISPLAY T1.Field1 T1.Field2 T2.Field5
END.
And launch this inside the programming environment (F2).
In case of syntax mistakes, the compiler shows the errors. In case the syntax is correct, a pop-up window is started, showing the results.
I have a migration written that executes just fine on my test database - did dozens of tests runs without issue. I run it on a clone of my prod database and all of a sudden I'm having all sorts of problems. I'm beginning to think its a database config or permissions issue, but I'm logged into this clone as root, so I'm not even sure where to start looking...
If I copy the mysql statement from the error (...and fix the missing data) the statement executes without issue.
ALTER TABLE `retail_items-tmp_09-10-2020` CHANGE original_inventory initial_inventory INT DEFAULT NULL;
The offending line:
Schema::table('retail_items-tmp_09-10-2020', function($table) {
$table->renameColumn('original_inventory','initial_inventory');
});
The Error:
[PDOException (42000)]
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-tmp_09-10-2020 CHANGE original_inventory initial_inventory INT DEFAULT NULL' at line 1
The migration:
public function up()
{
/* 1. Backup Existing Tables */
DB::statement('CREATE TABLE `retail_items-tmp_09-10-2020` LIKE `retail_items`; ');
DB::statement('CREATE TABLE `ARCH__retail_items_09-10-2020` LIKE `retail_items`; ');
DB::statement('INSERT INTO `retail_items-tmp_09-10-2020` SELECT * FROM `retail_items`; ');
DB::statement('INSERT INTO `ARCH__retail_items_09-10-2020` SELECT * FROM `retail_items`;');
/* 2. Update structure */
Schema::table('retail_items-tmp_09-10-2020', function($table) {
$table->renameColumn('original_inventory','initial_inventory');
});
Schema::table('retail_items-tmp_09-10-2020', function($table) {
$table->integer('event_ID')->length(11)->unsigned()->nullable();
$table->foreign('event_ID')->references('event_ID')->on('events');
});
/* 3. Update structure that would have been destructive prior to step 3 */
// When I had this piece of code included, it resulted in the same error "Syntax error or access violation..." this worked in testing, but throws errors on Prod, changed to DB:statement below with success.
// Schema::table('retail_items-tmp_09-10-2020', function($table) {
// $table->smallInteger('flag')->unsigned()->nullable(false)->default(0)->change();
// });
$query = "ALTER TABLE `retail_items-tmp_09-10-2020` CHANGE `flag` `flag` SMALLINT(11) DEFAULT 0 NOT NULL; ";
DB::statement($query);
}
I've been stuck on this for a bit, so any theories, places to look, etc would be appreciated.
(I have another migration that renames the temp table at the end of this. I have a few migrations and data operations that all together take ~ 10+ min to execute with the piece of code that I'm launching this with, so the temp tables are necessary to prevent downtime when launching in production)
I still ended up having more troubleshooting/ other roadblocks on this issue, so this only removed one...
Even though they were properly quoted, I read a number of S.O. posts on the subject and as Webtect suggests I did end up simply removing all the dashes and things worked much more consistently and reliably. I'm still feel like it's a mystery as to why this happened because I've used hyphens in dates like this before - properly quoted - without issue. But this one sure threw me for a loop. I think I will entirely stop the practice of using hyphens in dated-table-names going forward. They seem to cause more headaches than the improved readability warrants.
When I executed the code below i got the message "anonymous block completed" without any results back. Can anyone help me out?
BEGIN
FOR r IN
(SELECT DBMS_METADATA.GET_DDL
(object_type => 'VIEW', name => view_name, schema => USER)
AS view_text
FROM USER_VIEWS)
LOOP
IF INSTR (r.view_text, 'Project') > 0 THEN
DBMS_OUTPUT.PUT_LINE (r.view_text);
END IF;
END LOOP;
END;
Before running this piece of code, you have to enable output. In SQL*Plus and SQL Developer, it is done by running
set serveroutput on
PL/SQL Developer must have something similar, either by explicitly running that statement (if it is supported), or by clicking somewhere in the output window so that DBMS_OUTPUT has something to display the result to.
I have also found this (in case someone needed):
SQL Developer seems to only output the DBMS_OUTPUT text when you have explicitly turned on the DBMS_OUTPUT window pane.
Go to (Menu) VIEW -> Dbms_output to invoke the pane.
Click on the Green Plus sign to enable output for your connection and then run the code.
I try to execute list of SQL script files in SQLdeveloper, but it only executed only first line of statement.
C:/runAll.sql
#C:/sql/test1.sql;
#C:/sql/test2.sql;
#C:/sql/test3.sql;
#C:/sql/test4.sql;
#C:/sql/test5.sql;
.....
Try 1
At Oracle SQL Developer > File > open file >runAll.sql
Select all file list and press F5
Try 2
At Oracle SQL Developer > worksheet
#C:/runAll.sql
Try 1 and Try 2 does not work. It only executed only first line of statement(test1.sql).
Please help me
My findings using version 18.1...version 4.1 is from 2015, so you might want to consider upgrading your software.
Remove the ';'s
This works
Something is running on your side.
Show us the output and any errors, or you're asking us to guess. This is my guess.
I use sql server 2005 for an asp.net project. I want to run a SQL file that contains all DB changes from the last release to easily bring a DB up to the latest version.
I basically just have a bunch of alter table, create table, create index, alter view, call stored proc, etc statements. But I would like to wrap it in a transaction so if any part of it fails, none of the changes will go through. Otherwise it could make for some really messy debugging where it finished.
Also, if you know of a better way to manage DB deployment let me know!
I do something similar with a Powershell script using SMO.
Pseudocode would be:
$SDB = SourceDBObject
$TDB = TargetDBObject
ForEach $table in $SDB.Tables
{
Add an entry to a hash table with the name
and some attributes (rowcount, columns, datasize)
}
# Same thing for $TDB
# Compare the two arrays, and make a list of all the ones that exist in the source but not in the target, or that are different
# Same thing for Procs and Views
# Pass this list to a SMO.Scripter as an UrnCollection object, and it will script them out in dependency order (it's an option), with drops
# Wrap the script in a transaction and execute it on target server
# Use SQLBulkCopy class to transfer data server-to-server
What version of Visual Studio do you use? In Visual Studio 2010 and from what I can remember Visual Studio 2008 - in the menu under "Data" there are two options - "Schema Compare" and "Data Compare". That should move you in the right direction.
BEGIN TRANSACTION #TranName;
USE AdventureWorks2008R2;
DELETE FROM AdventureWorks2008R2.HumanResources.JobCandidate
WHERE JobCandidateID = 13;
COMMIT TRANSACTION #TranName;
You should execute everything within a transaction
Note that some DDL statements have to be the first statement in a batch (batches are separate from transactions). (GO is the default batch separator in SSMS and SQLCMD).