A task assigned to us by our professor states that we need to do the following:
Submit an sql script file containing your SQL statements to the following questions
CREATE A COLLECTION
CREATE ALL THE TABLES FROM ASSIGNMENT 1 SOLUTION UPLOADED TO BLACKBOARD
ADD THE PRIMARY KEYS AND FOREIGN KEYS TO THEM
INSERT (MINIMUM OF 3 RECORDS) TO EACH TABLE
UPDATE AND DELETE (MINIMUM OF 1 RECORD) FROM EACH TABLE
However, in non of the lectures has he used the term collection, I've always heard library and some other stuff. What is a collection?
I am using notepad++ and set the language to SQL, and I typed in
CREATE COLLECTION, however, create highlights in blue but collection does not have a colour assigned to it (nor does Library).
When I tried googling for an answer, I got this from IBM
"An SQL collection is the basic object in which tables, views, indexes, and packages are placed"
So a collection would just be a library wouldn't it?
so if that's the case, then in iSeries (AS/400) I would type on the command line
CREATE COLLECTION ASSIGN1
but in a script would that be the same thing?
Thanks for your time.
EDIT
My professor sent me this as an example, a .sql file that opens in a program from iSeries called "Run SQL Scripts", however, he didn't explain anything, just sent me this as an example.....so is it safe to assume Collection is the same as creating a Library?
CREATE COLLECTION FARA042;
CREATE TABLE FARA043.EMPLOYEE (
EMP_NUM VARCHAR(10) CONSTRAINT FARA043.EMPLOYEE_PK PRIMARY KEY,
EMP_FNAME VARCHAR(50),
EMP_LNAME VARCHAR(50));
SELECT * FROM FARA043.SYSTABLES;
SELECT * FROM FARA043.SYSCOLUMNS
WHERE TABLE_NAME = 'CHARTER';
You are correct. On IBM i (formerly known as iSeries, System i) the terms Library, COLLECTION, and SCHEMA all refer to the same thing. IBM now uses the term SCHEMA instead of the term COLLECTION, to conform to newer SQL standards, but they are synonymous. However, the term COLLECTION has been deprecated, and therefore should no longer be used.
There are however some subtle differences between CRTLIB and `CREATE SCHEMA' (or CREATE COLLECTION).
The CL command CRTLIB allows you to specify the description of the library, just as any IBM i object has an object description. You can also specify whether the library is to be treated as a *PROD or *TEST library when someone is debugging. On IBM i, when a developer starts debugging, one of the settings is a safety feature indicating whether the session will be allowed to update files (tables) in a *PROD library or not.
The SQL CREATE SCHEMA statement, on the other hand, not only creates a library, but sets it up with catalog views and automatic database journalling (logging).
Once you have created a schema in SQL, you can return to CL and use the CHGLIB command to set the library type and description, thus having the benefits of both methods.
One other difference, the SQL CREATE SCHEMA statement will allow you to create schemas with names longer than the IBM i 10-character standard. If you do this, I strongly suggest that you also give it a valid 10-character OS object name, by using the FOR SYSTEM NAME clause, otherwise the OS will then be forced to generate a 10-character library name.
Related
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)
Declaring a table variable with database name throws the following error.
The type name 'dbname.dbo.TableType' contains more than the maximum
number of prefixes. The maximum is 1.
Declare #cutoffDtes as dbname.dbo.TableType
However, the same works when I do the following
use dbname
Declare #cutoffDtes as dbo.TableType
Is there a way to declare the variable along with database name?
The documentation is pretty clear (once you find the reference) that user defined types are available only within a single database:
Using UDTs Across Databases
UDTs are by definition scoped to a single database. Therefore, a UDT defined in one database cannot be used in a column definition in another database. In order to use UDTs in multiple databases, you must execute the CREATE ASSEMBLY and CREATE TYPE statements in each database on identical assemblies. Assemblies are considered identical if they have the same name, strong name, culture, version, permission set, and binary contents.
In other words, you can repeat the definition in other databases and if everything is the same, then they are compatible.
EDITED for clarity:
I've created a table in DB2 using SQL.
I have now realized that I did not know the record format for the physical file created and need a Logical File to define keys to use in the RPG code. How can I accomplish this using SQL rather than DDS?
This was what I wanted to ask, really, now that I know a lot more on the subject.
There's really no difference between a PF created with DDS and a table created with SQL DDL.
Both methods result in a *FILE object with an attribute of PF.
The resulting object from either method can be used with SQL or with RPG record level access (RLA).
You can create DDS LF's or SQL views/indexes over a DDS created PF or an SQL DDL created table.
IBM provides tools to generate SQL DDL for a DDS created object, but not the other way around. You might be able to find a 3rd party tool designed to generate DDS if you lose your DDS source.
Best practice now-a-days is to use SQL DDL; as many recent enhancements to the DB are not available when using DDS.
If you think you need to use DDS for compatibly with RPG for instance, you are incorrect. All you need to do is take advantage of IBM i specific keywords.
Instead of
create table my_long_table_name (
my_long_column_name char(10)
);
Use
create table my_long_table_name
for system name mytable (
my_long_column_name
for mycol char(10)
) rcdfmt mytabler;
I'm trying to get work my play20 application with postgresql so I can use and later deploy to Heroku. I followed this answer.
Basically, I made connection to database (so connection from local application to Heroku postgresql database worked), but I was not able to initialise database with generated 1.sql evolution. But generated sql was not working because of postgresql is using schema (it should work without schema anyway, but apparently I'm doing something wrong or database is doing something wrong).
create table user (
id bigint not null,
email varchar(255),
gender varchar(1),
constraint pk_user primary key (id));
resulted in
ERROR: syntax error at or near "user"
Position: 14 [ERROR:0, SQLSTATE:42601]
I fixed that with adding schema to table name
create table public.user(
...
);
Ok, everything worked until I tried to read or write to database. I got again sql syntax exception and can't work with database. Seems like sql queries are somehow wrong.
Any suggestions where could be problem?
That's very common mistake while developing application with other database than in production, but fortunately there is also common solution. You can still use User model, however you have to make sure that creates database table with changed name:
#Entity
#Table(name = "users")
public class User extends Model {
...
}
In most cases in your controllers and models name-switch will be transparent for you. Only place where you have to remember the switch are RawSql queries.
BTW, that's good idea to install locally the same database for developing cause there's a lot of differences between most popular databases, like other reserved keywords, other allowed types, even other auto incrementing methods for id, so finding and fixing proper values is just easier on localhost.
Well, due to my little knowledge about postgresql, I was struggling with this all day. Here's simple solution. Don't use table called "user" on postgreqsl. This table is already used.
But why my evolution sql query worked for initialisation of database? Well if I explicitly specify in which schema I want to create table "user", that basically works.
But if schema is not specified, is used current schema. From documentation:
If a schema name is given (for example, CREATE TABLE myschema.mytable ...) then the table is created in the specified schema. Otherwise it is created in the current schema
So that explains it. But for my project, using "user" model was perfectly reasonable and for H2 file based databased it was working, so I assumed that problem was somewhere else...
Part of a reporting toolkit we use for our development is configured to always use the same schema (say XYZZY).
However, certain customers have stored their data in a different schema PLUGH. Is there any way within DB2/z to alias the entire schema XYZZY to refer to the objects in schema PLUGH?
The reporting toolkit runs on top of ODBC using the DB2 Connect Enterprise Edition or Personal Edition 9.1 drivers.
I know I can set up individual aliases for tables and views but we have many hundreds of these database objects and it will be a serious pain to do the lot. It would be far easier to simply have DB2 auto-magically translate the whole schema.
Keep in mind we're not looking for being able to run with multiple schemas, we just want a way to redirect all requests for database objects to a single, differently named, schema.
Of course, if there's a way to get multiple schemas on a per-connection basis, that would be good as well. But I'm not helpful.
I am guessing that by DB/2 schema you mean the qualifying name in some two part object name. For
example, if a two
part table name is: PLUGH.SOME_TABLE_NAME. You want to do define XYZZY as an
alias name for PLUGH so the reporting program can refer to the table as XYZZY.SOME_TABLE_NAME.
I don't know how to directly do that (schema names don't take on aliases as far as I am aware).
The objection you have to defining individual alias names
using something like:
CREATE ALIAS XYZZY.SOME_TABLE_NAME FOR PLUGH.SOME_TABLE_NAME
is that there are hundreds of them to do making it a real pain. Have you thought about
using a SELECT against the DB/2 catalogue to generate CREATE ALIAS statements for
each of the objects you need to refer to? Something like:
SELECT 'CREATE ALIAS XYZZY.' || NAME || ' FOR PLUGH.' || NAME
FROM SYSIBM.SYSTABLES
WHERE CREATOR = 'PLUGH'
Capture the output into a file then execute it. Might be hundreds of commands,
but at least you didn't have to write them.