DB2 AS400 & RPG please explain relationship - db2

DB2 AS400 & RPG
Please explain relationship in simple way since I'm quite confuse after doing some research
So far I understand DB2 is a kind of database for AS400 System written in RPG programming Language.
Is this correct?

The AS/400 series (consisting of AS/400s at first, and then iSeries, System i and later systems) has DB2 as the DBMS. DB2 is tightly integrated with the OS and with all compiled languages used on the system. DB2 is a relational DBMS that may be accessed and maintained via SQL.
RPG is a programming language and is the most commonly used language for business programming on the AS/400 series. There are two most common "flavors" of RPG on AS/400s: the older RPG III and newer RPG IV. (There can also be even older RPG II, but it's mostly irrelevant for this question.) You'll usually see RPG III referred to as RPG/400 or OPM RPG, while RPG IV is referred to as ILE RPG.
OPM stands for 'Original Programming Model'. ILE stands for 'Integrated Language Environment'.
Those two terms generally apply to many compiled languages on the AS/400 series. So, there is also ILE COBOL and OPM COBOL, as well as ILE C/C++ and others. The implementation of the ILE in 1994 allowed the various language compilers to compile "modules" that could subsequently be bound together to create "bound programs". Any ILE language could then call procedures in bound modules compiled from any other ILE language. So, one "program" might consist of procedures written in C, RPG, COBOL and even CL (the compiled 'Control Language').
Database access by RPG (and most other compiled languages) can be done through "native" access methods using verbs such as READ, WRITE and others; or standard SQL statements can be embedded such as SELECT, FETCH, INSERT/UPDATE/DELETE, etc. Either way, the database that is accessed is a DB2 database.
The OS is 'object based'. Because of that, tables and views are also compiled 'objects', either compiled from source code known as DDS or created with SQL by CREATE TABLE and CREATE VIEW statements. The compiled languages can generally use either older 'native' methods or SQL to access data in DDS or SQL-generated files. The underlying implementation is essentially the same, so both access methods work either way.
In short, DB2 is a DBMS. It's all about creating and maintaining tables, views and related database objects. It may be compared to Oracle or SQL Server.
And RPG is a compiled programming language, somewhat like C or COBOL. Programmers code RPG programs in order to control how users interact with DB2.

Related

Is it possible to create a user defined aggregate function for DB2 without the privilege to upload compiled files..?

Before I embark on a quest which ultimately proves hopeless, I'd like to ask those with greater experience...
Is it possible to create a user defined aggregate function for DB2 without privileges to upload compiled files..? This is for DB2 for AS400 on iSeries v7r3m0.
My first thought was to create the UDAF as a normal SQL function via my SQL client DBeaver 5.2.5. I've created regular UDFs this way before, however I'm not sure if an aggregate function can be written this way. I have yet to find any examples online, and this one IBM document isn't for my version.
If this cannot be done in SQL, then the next option is JAVA. My skills there are basic yet sufficient to explore the possibility, but it'd be my first time doing so on DB2. What may be the major roadblock there is in my understanding that JAVA functions for DB2 require uploading compiled files to the server, but I do not have privileges to do this. Unless I'm incorrect on this point..?
My next thought was whether JAVA functions can be written and compiled on the server..? For instance, can I write JAVA code in a script window of my SQL client, so when I run the script, the JAVA is compiled by the server, and then stored on the server..? Or perhaps is there's a JAVA development client like IBM Data Studio which connects to the server just the same..?
Or...something..? Any suggestions would be greatly appreciated.
I'll explain the UDAF I wish to create. It would be similar to any built-in UDAF like SUM(), but it would be character-based, and its name would be GetCommonWords. The input would be a table column of type CHAR(n). The output would also be CHAR(n), with a string of words that are common to the beginning of all records.
Consider the following phrases for the column "FOOD":
peanut butter
peanut butter and jelly
peanut butter cup
peanut butter jelly time
The usage would be GetCommonWords(Food), and the result would be the words common to all: peanut butter.
Db2 for i does not have a CREATE FUNCTION (aggregate) statement even in the current 7.4 release.
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_74/db2/rbafzcreatef.htm
You should know that Db2 for i, Db2 for z and Db2 (for LUW) are essentially separate products, and although there is certain amount of common syntax and features, you do need to look at manual pages (and web articles etc) for your particular platform (and ideally version level)

Is pgmodeler only used for PostgreSQL?

pgmodeler is said to be PostgreSQL Database Modeler.
As far as I know it is for relational database design, and relational database design isn't RDMBS specific.
So is pgmodeler only used for PostgreSQL? Can it be used with other RDBMS, such as mysql, sqlserver, oracle database?
What part of pgmodeler is postgresql specific, and what part of it is not?
Thanks.
It is specific to postgresql in the sense that it supports everything that posgresql does : sql extensions ("create table like..."), its procedural language pl/pgsql, foreign data wrappers, table partitioning, among many many others ; and these are usually totally incompatible with other RDBMS.
But the main developper is studying closely an integration with pgloader, which would make such a compatibility a thing in a near future.
If you stick to the pure design features of pgmodeler, "keep it classic" and never go for an implementation, then pgmodeler is somehow universal.
Edit : To answer more precisely, the model is "universal", the code produced when you export the model to a database is specific to postgresql (sql data types, extensions...).

Migration from Postgresql to SQLite

I am working on a project which uses PostgreSQL on the backend to handle database. As PostgreSQL has procedural languages i.e. PL/pgSQL support, existing code contains various user defined functions.
Now I want to migrate to SQLite which does not have support for procedural langauges, I think. How can I handle this situation in SQLite and use same code fragment (i.e. functions) different time by just calling it.

Matlab's JDBC/ODBC SQL behaviour differs from Access 2010

This is a hybrid question & public service announcement. The basic question is whether there are convenient and/or efficient workarounds to the limitations listed below. I spent half the morning discovering that one cannot just transplant SQL code from Access to Matlab. I've boiled it down to 3 points so far.
Can't use double quotes in SQL statements to avoid collision with
Matlab's string delimiter. The Matlab code for the SQL code strings
can become quite complicated, especially if the SQL strings already
use repeated single-quotes to represent a single quote within a
string constant.
Must always specify a source table from which to query. What won't
work is "SELECT #2015-07-28#". One basically needs to create a 1-row dummy table.
Must always select at least one field in the table being queried.
An asterisk does not seem to suffice.
The above limitations do not exist when submitting SQL code using the Access Query Designer (either in SQL 92 mode or not), nor do these limitations exist when submitting SQL code using VBA via CurrentProject.Connection.Execute.
Hopefully, this saves someone else some time in learning about these differences. And if anyone has found a workaround, that would be appreciated. Note that the above is in the context of using the JDBC/ODBC bridge (3rd of 3 illustrated configurations in the drivers documentation. The database toolbox documentation for directly connecting to an Access file using code (rather than setting up a data source using the GUI) only describes a code pattern that uses the JDBC/ODBC bridge. This is described in Example "Connect to Microsoft Access Using a File DSN" in the "Connect to database" page. I'd like to stick to this approach because I want to quickly be able to directly specify the source *.accdb file without jumping through GUI hoops of setting up a data source.
I've posted this to:
Stack overflow
Usenet
While I have not connected Matlab to Access, I have connected Access databases to PHP, Python, SAS, R, even Excel without any issues with quotes or asterisk. As for the needed source table in queries that is simply due to the Jet/ACE SQL dialect as each dialect have their particular rules. But your query above should work for one-row, one-column output of such date. SQL Server does not require a source table but Oracle does. Access dates are in the MM/DD/YYYY format, requiring # in conditional statements. MySQL use dates in YYYY-MM-DD format, requiring single quotes.
Are you using Windows installed Jet/ACE ODBC drivers? Do note these drivers are softwares external to any application (not part of Access) and can be used by any client interfacing to any data source. Aside - many are not aware that Access' backend database engine, Jet/ACE is actually a Windows technology and not restricted to Access; PC users without Access installed can still use this engine. Hence, connection strings are standard across ODBC calls. And as I see you can apply same principles to Matlab database connections.
With that said, my suggestions/workarounds:
properly learn the SQL dialect for connecting database and check if query runs; even optimize or re-write as needed
try escaping various punctuation not compliant in Matlab strings or use the ASCII counterparts: chr(34) for double quote; chr(39) for single quote; chr(42) for asterisk.
if select statements are limited in Matlab strings, create a temp table from query (use make-table query SELECT * INTO newtable FROM query outside of Matlab), then connect to this new table
use intermediary coding language (VBA, Python, C#) by user trigger or
command line to connect to database and export needed dataset, then
automate Matlab to import
export query to flatfile format (csv, txt, etc.) for Matlab import

How compatible is Blackfish database with TSQL?

I'm using a sqlServer database that has stored procedures, and I want to use an in-memory database to unit test my code.
I've looked at a few - including VistaDB which looks amazing but expensive - and Blackfish seems to be the only possiblity so far. Before using it though i'd like to know exactly how compatible it is with TSQL - obviously if I have a lot of existing stored procedures these will use TSQL, so it's important that the in-memory db I use can handle this.
Thanks
Short Answer: Not Very
Long Answer:
Whilst Blackfish is SQL-92 compliant, you’re bound to run into stuff that worked on your T-SQL database that won’t work on BlackFish.
I'd strongly recommend SQL Server Compact 4.0 (or Express at a crunch), Compact can be easily bundled, has a tiny footprint (3mb installer? [18mb on disk ish]).
For instance, T-SQL Flow control might differ to Blackfish flow control - not really relevant for selects, inserts & updates etc, but if you have T-SQL logic gates in stored procedures, i don’t think these will port to Blackfish? Blackfish supports stored procedures, but they are compiled in other native languages (Delphi mainly). Good example from the documentation:
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/bfsql/storedprocedures_xml.html
Very different from the T-SQL procedures used in MS SQL