-
Date() gibt immer den Typ Date zurück.
Einzig bei der Funktion CHAR(DATE()) wird das Jobformat berücksichtigt und kann ggf. zum Fehhler führen (< 1.1.40 oder > 31.12.39).
Dies kann man aber mit CHAR(DATE(), ISO) umgehen.
-
Thx,
wieder was gelernt
(stimmt natürlich, ich verwende Char(date(...)
Robi
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
Unter 7.1 sollte es auch so funktionieren:
Code:
Select ...
Int(VarChar_Format(Timestamp_Format(Digits(Datum), 'YYYYMMDD') + 1 Day, 'YYYYMMDD'))
From ...
Ab 7.2:
Kann man's dann etwas vereinfachen:
Code:
Select ...
Int(Date(Timestamp_Format(Digits(NumDatum), 'YYYYMMDD') + 1 Day))
From ...
Birgitta
-
Schön, wer V7ff hat, wenn man noch auf V5R2 bis V6R1 arbeitet .
-
Glaubst Du ich kann auf 7.xx arbeiten?
Das hindert mich dennoch nicht zu wissen, was alles möglich ist und mich ggf. darüber aufzuregen, dass ich es nicht nutzen darf.
Ich muss auch noch alles auf die V5-Versionen umwandeln ... und manchmal darf ich dann auch Programme in doppelter Ausführung erstellen! Gerade erst gestern musste ich 2 Varianten für ein (SQL-)Programm schreiben, damit die Kunden, die Release 7.xx haben nicht unter denen leiden müssen, die sich keinen Upgrade gönnen.
Release V5R4 ist inzwischen über 10 Jahre alt!
Wer hat noch PCs bzw. die entsprechende Software die genauso alt oder älter sind am laufen???
Nur an dieser Stelle rumzujammern nutzt nix! Diejenigen, die sich nicht bewegen lesen auch keine aktuellen Artikel oder Blogs oder Foren.
Birgitta
-
Gerade erst gestern musste ich 2 Varianten für ein (SQL-)Programm schreiben, damit die Kunden, die Release 7.xx haben nicht unter denen leiden müssen, die sich keinen Upgrade gönnen.
OT ... und ich liebe das neue "Free" Format TR7, auch wenn ich anfangs sehr skeptisch war. /OT
kf
-
 Zitat von Fuerchau
Schön, wer V7ff hat, wenn man noch auf V5R2 bis V6R1 arbeitet  .
... wichtiger als das neueste Release ist es - nach meiner unbescheidenen Meinung - sich möglichst nahe am SQL Standard zu halten. Nicht primär wegen Portabilität, sondern um möglichen Konflikten bei Erweiterung des Standards auszuweichen. Setzt man proprietäre Erweiterungen des Standards ein, die leider immer mehr ausufern, besteht stets das Risiko, dass diese Konstrukte mit späteren Erweiterungen des ANSI SQL kollidieren, also nicht mehr lauffähig sind. Momentan gibt es drei Hauptbeteiligte des Standardisierungs Prozesses: Oracle (incl. MySQL), MS mit SQL Server und IBM, wobei IBMS Position (und damit der Einfluss auf den Standard) schwächer wird.
Zudem sind bei den Neuerungen auch viele Quatsch-Features von Marketiers, die man in der Praxis nicht benötigt. Ein anderer Punkt ist noch, dass Beschränkung auf weniger Konstrukte in den allermeisten Fällen die Lesbarkeit wesentlich verbessert.
D*B
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks