I'm still baffled that examples given in the SAP keyword documentation are not accepted in a system of the respective ABAP version.
I'm trying to run the example given for SELECT datasource~* ... on an ABAP 7.40 system but get the error
"," is not allowed here since it contains an invalid character or it is a keyword [...]
When removing the ,, the error is
No component exists with the name "*". "*".
The example in the keyword documentation is
TYPES BEGIN OF structure.
TYPES carrname TYPE scarr-carrname.
INCLUDE TYPE spfli AS spfli.
TYPES url TYPE scarr-url.
TYPES END OF structure.
DATA itab TYPE STANDARD TABLE OF structure WITH EMPTY KEY.
SELECT scarr~carrname, spfli~*, scarr~url
FROM scarr INNER JOIN spfli ON scarr~carrid = spfli~carrid
INTO TABLE #itab.
cl_demo_output=>display( itab ).
What would be a correct example? And/or: which ABAP version should my system have to accept this example (and how to check that)?
The keyword documentation you already referred to states that
When data_source~* is used, the syntax check is performed in a strict
mode, which handles the statement more strictly than the regular
syntax check.
The documentation page on the strict mode is titled
Strict Mode in Release 7.40, SP08
so I would assume that you need at least SAP_BASIS 740 SP08.
I just copied that sample code and it works like a charm on my 7.40 SP11 system. You should check what SP level your Netweaver has. It can be done in the following way:
Go to System -> Status from the main menu
Press on the Component button in SAP System data to see component versions of your system.
You should see something like this:
SAP_ABA component is your ABAP server, and SP-Level column represents patch level of your AS.
Necessary patch level can bee seen in ABAP Release-Specific changes section of documentation, and here we can observe that this syntax is available since 7.40, SP08.
There is no searchable index of release-specific changes so you should search it manually.
Related
I'm using DBeaver to write script for my PostgreSQL database.
I have a PostgreSQL DB with Tables autogenerated by C#/EFCore (Microsoft ORM) - I receive SQL Error [42P01] if I don't add double quotes around table names when I cut and paste my ORM queries to DBeaver. I got [42703] for fields without double quotes. I do not have to add double quotes in C# code but it appears to be required in DBeaver?
example:
select * from Dnp3PropertyBase => SQL Error [42P01]
select * from "Dnp3PropertyBase" => OK, all results shown...
Does anybody know if I can change a parameter in DBeaver somewhere in order to enter table names and fields without double quotes?
Note: Using DBeaver 22.3.2 (latest on 2023-01-11)
Update After reading: Postgresql tables exists, but getting "relation does not exist" when querying
show search_path => public, public, "$user"
SELECT * FROM information_schema.tables => All tables are in public schema
SELECT * FROM information_schema.columns => All columns are in public schema
Question: How to be able to cut and paste my EFCore generated queries from Visual Studio output window to DBeaver query without having any errors regarding table names and field names?
First let me copy #a_horse_with_no_name comment:
Unquoted names are folded to lower case in Postgres (and to uppercase
in Oracle, DB2, Firebird, and many others). So SomeTable is in fact
stored as sometable (or SOMETABLE). However quoted identifiers have to
preserve the case and are case sensitive then. So "SomeTable" is
stored as SomeTable
Many peoples recommended me to go with snake case which I didn't want to go with initialy because all tables were auto generated by EF Core (Microsoft C# ORM). I told myself that Microsoft would do standard things. Microsoft use the exact "class" name in code as the table name , by default. That appears to me very logical in order to stay coherent and apply the same rules everywhere. C# recommended to use Camel case for classes so each table names end by default in Camel case instead of snake case.
PostgreSQL seems to promote users to use snake casing because they lower case every non double quoted names. According to a_horse_with_no_name, and I think the same, only PostgreSQL has the behavior of lower casing down every table names and field names which are not double quoted in SQL script. That behavior (changing casing for non double quoted names) appears to me as being very limitative. It also has hidden effect that could be hard to find for non initiated peoples coming from other DB world.
According to PostgreSQL doc, they recommend to use nuget package (.UseSnakeCaseNamingConvention()). It probably works fine for TPH (table per hierarchy) which is recommended by Microsoft for performance. But it does not works for table name for TPC (table per class) because of actual bugs in EFCore 7 (see Github project).
I received that message at the end of "update-database":
Both 'WindTurbine' and 'ResourceGenerator' are mapped to the table
'resource_generator'. All the entity types in a non-TPH hierarchy (one
that doesn't have a discriminator) must be mapped to different tables.
See https://go.microsoft.com/fwlink/?linkid=2130430 for more
information.
PostgreSQL doc : TPH supported OK but not for table in TPC (2023-01-12). I use TPC then I had to force each table name directly through TableAttribute.
My solution For table name, I use snake casing by manually add a "Table" attribute to each of my classes with the proper name like this sample:
[Table("water_turbine")]
public class WaterTurbine : ResourceGenerator
For fields, I use the EFCore.NamingConventions NugetPackage which works fine for fields names. Don't forget that if you have 2 classes mapped to the same object, it is because you are using TPC and did not force table name through TableAttribute.
This way all my table and fields names are snake casing and I can cut and paste any query dumped in my debugger directly in any SQL script window of DBeaver (or any SQL tool).
Is there any advantage of using standalone table type vs the table type we create inside package spec or body in terms of efficiencies apart from below differences:
Standalone Table Type can be used in multiple places. Package table type can be used inside the package. Some may argue that we can create a common package spec and use the table type from package spec.
additional db object to maintain for standalone table type
If you mean something like this for example
type some_type is table of number;
then storing it in a separate package can help you to keep it together with another logically related objects. And giving access to those objects will be easier because you don't need to specify each object but just give access to the package.
And keeping it private for a package as you've mentioned in 1. can also be a reason why one can deside for using a package
Some operations require the type defined as global type, e.g.
select ...
into ....
from TABLE(<your table type variable>);
does not work with locally defined type (at least this was the case in earlier Oracle versions)
I have the following generated column defined within a CREATE TABLE statement:
NET_ROWS_ADDED NUMBER(18) GENERATED ALWAYS AS (ROW_COUNT - PREV_ROW_COUNT) /*STORED*/,
ROW_COUNT and PREV_ROW_COUNT are simple NUMBER(18) columns previously defined in the same table.
Everything works fine as it's written.
But if I un-comment the STORED option, I get:
ORA-00907: missing right parenthesis
I need to convert this into a STORED generated column.
What is wrong with the syntax here? It all looks correct to me ...
Oracle doesn't store a virtual column on disk, it is only evaluate on demand. You are probably confused with the STORED option in MySQL. Since there is no STORED clause in Oracle, it throws a syntax error.
From documentation:
GENERATED ALWAYS
The optional keywords GENERATED ALWAYS are provided for semantic
clarity. They indicate that the column is not stored on disk, but is
evaluated on demand.
VIRTUAL
The optional keyword VIRTUAL is provided for semantic
clarity.
There is an overview of which products supports stored (and other storage options) at modern-sql.com. Pictured: support for the stored options as of late 2022.
My simple question is as follows:
If I have a Microsoft Access database with a defined "query" in it (i.e. the kind of database object that MS Access calls a Query, just to avoid any ambiguity) defined to take parameters (using a PARAMETERS declaration inside its SQL definition) what is the correct SQL syntax to call it over an ODBC connection, including providing the parameter values?
EDIT / ADDITION:
I just noticed that it could be done by adding curly-braces around the entire CALL command, as follows:
{CALL myAccessQuery ('string1', 'string2', 'string3')}
This was actually exactly what they already did in the other related SO thread that I'm referring to here below, but I just thought that this was some C#-specific magic related to the prepared-statement nature of their SQL statement (using "?" in it), or some other peculiarity of their SQL library (I'm not using that language), so I previously ignored it.
Anyone who will explain what the curly-braces are, and why they allow for execution of more SQL commands than the explicitly stated supported ones in the error message below, will be an accepted answer for this question.
Some more details for my specific case:
My query takes three parameters, defined by a "PARAMETERS" clause in the beginning of the query's declaration, as so:
PARAMETERS myParam1 Text ( 255 ), myParam2 Text ( 255 ), myParam3 Text ( 255 );
SELECT ... <a bunch of not relevant stuff here> ;
Using an (already established and confirmed working) ODBC connection, I want to use this query from an external application, including providing the required three parameters for it.
Running normal queries like SELECT etc works just fine over the connection from my external application, but no matter how much I google, I cannot seem to find out the proper way to correctly provide the parameters for and run my query? So, again, my question is, what is the correct SQL syntax for doing this?
NOTE: I do NOT want any API specific solution for some certain library or similar, since this only solves the problem for a very small part of all developers who want to do this from different programming languages, so for this reason, I won't even bring up what language my external application is written in. I just want the full SQL syntax for doing this, nothing more, nothing less.
Another SO question indicates that this should be done using the "CALL" keyword, but when I try to use this from my application, I just get the following error message:
[42000] [Microsoft][ODBC Microsoft Access Driver] Invalid SQL statement; expected 'DELETE', 'INSERT', 'PROCEDURE', 'SELECT', or 'UPDATE'.
I.e., this is the "SQL command" (purposely avoiding the ambiguous term "query"...) that I'm trying to execute when getting this error:
CALL myAccessQuery ('string1', 'string2', 'string3')
The only one of the SQL keywords mentioned in the error message that seem likely to be useful is the "PROCEDURE" keyword, but I'm having similarly big difficulties finding any relevant documentation also for this on Google. :-(
I suspect that most of Google's lack of results in regards to this entire scenario comes from the many involved ambiguities regarding more or less all the central keywords in the context, like "queries", "parameters", "execute", "call" and "procedure", so with this SO question my hope is that it will constitute a somewhat more easily identified and indexed answer for this question to be presented by Google in the future.
When you're connecting over ODBC, look at the driver-specific information to see if it supports the various ODBC extensions (indicated by curly braces in the ODBC calls):
https://msdn.microsoft.com/en-us/library/ms675326(v=vs.85).aspx
Specifically:
ODBC provides a specific syntax for calling stored procedures. For the CommandText property of a Command object, the CommandText argument to the Execute method on a Connection object, or the Source argument to the Open method on a Recordset object, passes in a string with this syntax:
"{ [ ? = ] call procedure [ ( ? [, ? [ , … ]] ) ] }"
Each ? references an object in the Parameters collection. The first ? references Parameters(0), the next ? references Parameters(1), and so on.
The parameter references are optional and depend on the structure of the stored procedure. If you want to call a stored procedure that defines no parameters, your string would look like the following:
"{ call procedure }"
The Access ODBC driver exposes saved SELECT parameter queries as Stored Procedures, so that's why you use this syntax.
Perfectly fine ms-sql statement
SELECT distinct ProductLineCode ,
(SELECT CAST(ItemName + ', ' AS VARCHAR(MAX)) FROM Product spt
where spt.ProductLineCode = pt.ProductLineCode FOR XML PATH (''))
as ItemNames FROM Product pt where ProductLineCode is not null
cause error when executed as native query in hibernate.
org.hibernate.MappingException: No Dialect mapping for JDBC type: -16
I guess that JDBC type: -16 is boolean but that says me nothing. Product table has xml mapping and works well for months.
Could you please guide me what to try next?
You might as advised in comments be able to get something similar to work by changing the types in the sql.
But if that doesn't bring success, you might also be able to tell hibernate how to deal with this type by changing the Dialect class used by your application, possibly even extending the one currently used and adding a registration for the missing type.
It appears that your missing type mapping is for the type java.sql.Types.LONGNVARCHAR (by code grep, the value is -16), so a Dialect extension with a call something like
registerColumnType( Types.LONGNVARCHAR, "text" );
in the constructor may convince hibernate to treat this field as text.
If you do this you'll have to change the configuration to use your dialect by modifying the line
<property name="dialect">org.hibernate.dialect.SQLServer2012Dialect</property>
to use your own dialect class. (Note: the class in there is just a guess at what you might have there now.)
It's also possible that you just have hibernate using the wrong dialect for your DB, in which case just changing the configuration to the appropriate one would be better.
It's rarely necessary to use a custom Dialect, but this may be one of those times.