Wie ist der richtige Ablauf der Erstellung einer Datenbank auf der AS/400

[watchdogg]

Danke euch allen.

Das mit dem Create Schema habe ich gemacht.
Anschließend mit i Access - Client Solutions die Tabellen erstellt.
Die äußerst umfangreiche Referenz habe ich mir auch runtergeladen - es gibt da scheinbar schon einige spezielle SQL-Statements gegenüber anderen DBMS.
Aber alles machbar.

Meine erste ASP.NET Anwendung läuft bereits mit der neuen Datenbank (immerhin 2 Tabellen :-) ).
Gemappt habe ich die Tabellen mit dem OpenSource ORM Dapper - welches ich .NET Programmierern sehr ans Herz legen möchte.
Gerade in Sachen Datenbindung (@B.Hauser) System i (AS/400) ein guter EntityFramework-Ersatz!

Auf jeden Fall habt ihr mir sehr weitergeholfen, sodass ich in der Richtung jetzt weiterkomme. Ich möchte nämlich eine Art GUI für Windows bauen, um Daten besser aus dem PPS auf unserer Maschine auszulesen.

Viele hier arbeiten noch mit der 5250-Emu - das macht vor allem neuen Mitarbeitern stark zu schaffen!


Gruß, watchdogg

[BenderD]

Die äußerst umfangreiche Referenz habe ich mir auch runtergeladen - es gibt da scheinbar schon einige spezielle SQL-Statements gegenüber anderen DBMS.
Gruß, watchdogg

... die man möglichst nicht verwenden sollte!!!

D*B

[watchdogg]

create table schema.person (
id integer not null GENERATED ALWAYS AS IDENTITY
(START WITH 1 INCREMENT BY 1),
anrede varchar(20),
vname varchar(40),
nname varchar(40),
geburt date,
strasse varchar(40),
PRIMARY KEY (id))

Das AUTO_INCREMENT habe ich z.B. nur mit dem Befehl hinbekommen.

[BenderD]

create table schema.person (
id integer not null GENERATED ALWAYS AS IDENTITY
(START WITH 1 INCREMENT BY 1),
anrede varchar(20),
vname varchar(40),
nname varchar(40),
geburt date,
strasse varchar(40),
PRIMARY KEY (id))

Das AUTO_INCREMENT habe ich z.B. nur mit dem Befehl hinbekommen.

... das ist ANSI SQL 2003, wenn Du was anderes kennst, dann solltest Du überprüfen, ob die andere Datenbank die ANSI Formulierung auch kennt.
Je näher man sich am Standard hält, umso weniger Probleme hat man beim portieren. Das gilt auch für Oracle, MySQL, MS SQL Server, da werden oft nicht Standard Konstrukte verwendet, auch das sollte man sich tunlichst abgewöhnen.

D*B

PS: da gibt es auch ein schönes Tool: http://www.sqlines.com/online

[Fuerchau]

Der VS-Datenprovider wird von CA doch mitgebracht (ODBC/OLEDB/native .Net-Treiber).
So wie eigentlich jede Datenbank.

[Fuerchau]

Wenn ich DDL-Statements von Oracle oder Microsoft adaptieren muss, gibt es kein einziges Script, dass nicht manuell überarbeitet werden muss.
Problematisch ist dabei immer der Datentyp DateTime, da es den so auf der AS/400 nicht gibt.
Den muss man als Timestamp ersetzen, darf ihn aber so nicht mit dem SQL-Server austauschen.

Was die .Net-Integration angeht, so bin ich eigentlich mit der VisualStudio-Unterstützung äußerst zufrieden was die Erstellung von streng typisierten Datasets, Queryabfragen und generierten DBAdaptern angeht sowie den dazugehörigen Datenbindungen.

[watchdogg]

Du hast aber sicher einen kostenpflichtigen Datenprovider von IBM mit Visual Studio Integration Tools, oder?