Trying to create xsodata via dbprocedure
"X"."SHOPLIST/Header" as "Header"
navigates ("ToItem" as "ItemRef")
create using "X"."SHOPLIST.shoplist::create";
it says Syntax error at line: 3, column: 15.
create using "SHOPLIST.shoplist::create";
it says Unknown object "SHOPLIST.shoplist::create".
Procedure name is "X"."SHOPLIST.shoplist::create" (it works ok in console).
So it seems that xsodata doesn't work with DB artifacts. I had to create .hdbprocedure and then it would accept it without schema prefix...
Related
I have created a Babelfish-enabled Postgres database in RDS.
I connected with SSMS and created a Database named 'demo'.
Within 'demo' I created a Schema named 'biz'.
I created my tables and stored procedures in the 'biz' schema.
The stored procedures used unqualified table names.
Finally, I wrote a .Net program to do some testing.
I use the System.Data.SqlClient Connection and Command classes and I can connect to the database.
When I execute a stored procedure I get the 'relation "X" does not exist.' error.
If I alter my stored procedure and qualify the table names with the 'biz' schema the error goes away.
How do I avoid having to qualify the table names with the schema?
For example:
After creating a Babelfish enabled Postgres cluster I executed these statements in SSMS:
create database demo
use demo
create schema biz
create table [biz].[cities](
[city] varchar(128),
[state] varchar(128)
)
create procedure [biz].[p_getcities] as
begin
select * from cities
end
insert into [biz].[cities](city, state) values ('Portland', 'OR')
insert into [biz].[cities](city, state) values ('Richmond', 'VA')
exec [biz].p_getcities
And I get this error message after running p_getcities:
Msg 33557097, Level 16, State 1, Line 21
relation "cities" does not exist
When I switch to pgAdmin and try to run the stored procedure like this:
CALL biz.p_getcities()
I get a similar error:
ERROR: relation "cities" does not exist
LINE 1: select * from cities
^
QUERY: select * from cities
CONTEXT: PL/tsql function biz.p_getcities() line 2 at SQL statement
SQL state: 42P01
However, when I set the search_path like this:
set search_path to biz
And the execute the stored procedure I get the expected results:
Portland OR
Richmond VA
Is there an equivalent to search_path in Babelfish?
This explanation has been provided by Rob Verschoor of rcv-aws
What is happening here is that the name resolution inside the procedure biz.p_getcities does not correctly resolve the table name. It resolves it to 'dbo' schema while it should resolve it to 'biz' schema. As you noted, this is related to the search_path setting, and this is not set correctly in this case.
This is a known bug and we hope to fix it soon.
Until then, the workaround is to qualify the table name with the schema name, i.e. select * from biz.cities
I am trying to run a stored proc "dbname..rr_deck_type_wrap_proc" through SQLDeveloper worksheet using the following code:
declare #return int, #message varchar(255)
exec #return = DBname..rr_deck_type_wrap_proc
#new_id = '123456789',
#remarks = 'Test',
#error_cd = #message output
select #return "#return", #message "#message"
However, I always get the message:
Error report - Invalid JDBC escape syntax at line position 22 '='
character expected.
This code works perfectly fine when run through another software/interface. It is probably a syntax issue with SQLDeveloper, tried different things but nothing worked. Can someone suggest anything. Thank you!
You're using 'Oracle SQL Developer' - the keyword there, being 'Oracle.'
You're connected to a SAP Sybase database. Which is perfectly fine. We provide this connectivity support for one reason, and one reason only:
To allow you to migrate it to Oracle Database.
It is NOT a T-SQL IDE. It does not provide any support really for running, debugging, playing with T-SQL.
If you have ANSI-SQL, then our parser will probably be OK with it.
If you need/want a hack, and are desperate to make your code go, then you can provide a hint to our parser, to just let the code go through to the driver, and hope it works.
An example:
/sqldev:query*/sp_help;
You could also try adding this
/*sqldev:stmt*/
This advice applies to MySQL, DB2, SQL Server, Teradata, or any other 3rd party JDBC driver we allow you to use in SQL Developer. It's there to help you move your schema and application code over into an Oracle Database.
New to the tSQLt world (great tool set) and encountered a minor issue with a stored procedure I am setting up a test for.
If I for some reason have a stored procedure which connects to mutiple databases or even multiple SQL servers (Linked Servers).
Is it possible to do unit tests with tSQLt in such a scenario?
I commented already, but I would like to add some more. So as I said already, that you can do anything that fits into the single transaction.
But for your case I would suggest to create synonyms for every cross database/instance object and then use synonyms everywhere.
I've created following function to mock view/tables synonyms. It has some limitations but at least it can handle simple use cases.
CREATE PROCEDURE [tSQLt].[FakeSynonymTable] #SynonymTable VARCHAR(MAX)
AS
BEGIN
DECLARE #NewName VARCHAR(MAX)= #SynonymTable+REPLACE(CAST(NEWID() AS VARCHAR(100)), '-', '');
DECLARE #RenameCmd VARCHAR(MAX)= 'EXEC sp_rename '''+#SynonymTable+''', '''+#NewName+''';';
EXEC tSQLt.SuppressOutput
#RenameCmd;
DECLARE #sql VARCHAR(MAX)= 'SELECT * INTO '+#SynonymTable+' FROM '+#NewName+' WHERE 1=2;';
EXEC (#sql);
EXEC tSQLt.FakeTable
#TableName = #SynonymTable;
END;
Without you providing sample code I am not certain of your exact use case but this information may help.
The alternative approach for cross-database testing (assuming both databases are on the same instance) is to install tSQLt in both databases. Then you can mock the objects in the remote database in the same way that you would if they were local.
E.g. If you had a stored procedure in LocalDb that referenced a table in RemoteDb, you could do something like this:
Imagine you have a procedure that selects a row from a table called localTable in the local database and inserts that row in to a table called remoteTable in the remote database (on the same instance)
create procedure [myTests].[test mySproc inserts remoteTable from local table]
as
begin
-- Mock the local table in the local database
exec tSQLt.FakeTable 'dbo.localTable' ;
-- Mock the remote table (not the three part object reference to remoteDb)
exec RemoteDb.tSQLt.FakeTable 'dbo.remoteTable' ;
--! Data setup ommitted
--! exec dbo.mySproc #param = 'some value' ;
--! Get the data from the remote table into a temp table so we can test it
select * into #expected from RemoteDb.dbo.remoteTable;
--! Assume we have already populated #actual with our expected results
exec tSQLt.AssertEqualsTable '#expected', '#actual' ;
end
The above code demonstrates the basics but I blogged about this in more detail some years ago here.
Unfortunately this approach will not work across linked servers,
Running Rails 4.0.13 with TinyTDS connected to Microsoft SQL Server 2012, I'm trying to run the following query:
sql = Model.where(:foo => bar).select(:open, :high, :low, :close).to_sql
Model.connection.execute(sql)
The problem is, the generated sql is
"SELECT open, high, low, close FROM [models]"
Which gives me an error as the column names open and close are protected.
TinyTds::Error: Incorrect syntax near the keyword 'open'
If I use #pluck, I can see the correct SQL is generated (with column names escaped):
"SELECT [models].[open], [models].[high], [models].[low], [models].[close] FROM [models]"
However, this produces an array, which is not what I want.
My question is how can i get #select to correctly quote the column names?
Thank you
I don't think you can make the select method to protect your column names when using symbols (maybe because different DBMS use different quoting identifiers), but you could pass your selection as a string :
sql = Model.where(:foo => bar).select("[open], [high], [low], [close]").to_sql
Model.connection.execute(sql)
I attempted to submit a bug report to Rails, however in doing so I saw the problem did not appear to exists using SQLite test case, this leads me to believe the issue is with the SQL Server Adapter.
Since I am on Rails 4 and not the latest version of the adapter I left it and wrote the following (horrible) method as wrapping the column names was not enough, I needed to prefix the table to prevent ambiguous column names. Yuck
def self.quote(*columns, klass)
columns.map { |col| "[#{klass.table_name}].[#{col}]" }.join(', ')
end
Recently I was tasked with creating a SQL Server Job to automate the creation of a CSV file. There was existing code, which was using an assortment of #temp tables.
When I set up the job to execute using BCP calling the existing code (converted into a procedure), I kept getting errors:
SQLState = S0002, NativeError = 208
Error = [Microsoft][SQL Native Client][SQL Server]Invalid object name #xyz
As described in other post(s), to resolve the problem lots of people recommend converting all the #tempTables to #tableVariables.
However, I would like to understand WHY BCP doesn't seem to be able to use #tempTables?
When I execute the same procedure from within SSMS it works though!? Why?
I did do a quick and simple test using global temp tables within a procedure and that seemed to succeed via a job using BCP, so I am assuming it is related to the scope of the #tempTables!?
Thanks in advance for your responses/clarifications.
DTML
You are correct in guessing that it's a scope issue for the #temp tables.
BCP is spawned as a separate process, so the tables are no longer in scope for the new processes. SSMS likely uses sub-processes, so they would still have access to the #temp tables.