Ökonomische Zukunft von ADS in der Anwendungsentwicklung

[RSF]

Arbeitet noch jemand mit ADS Datenbanken, vor allen mit Delphi Version 10.1 .
Bis heute gibt es keine neuen Komponenten für die aktuelle Delphi Version. Abgesehen von der manuellen Anpassung und Installation von Hand. Bin ich besser beraten die DB für die Zukunft zu wechseln? ( z.B. Firebird oder Postgres)

[jobo]

Ich bin neulich noch in einem Forum über ADS "gestolpert", genauer über das Unterforum für ADS. Es enthielt keinen Beitrag. Es kommt in meiner Welt nicht vor. (Was eine vollkommen subjektive Aussage ist)
Firebird, insbesondere die neue Version und PostgreSQL haben deutlich mehr Traffic. Firebird ist natürlich die Delphi Hausmarke bzw. die freie Konkurrenz. Empfiehlt sich bei Interbase nahen Anwendungen und vielleicht, wenn der Bedarf an Programmierung nicht so ausgeprägt ist. Dann eher Postgres. Es glänzt durch die starke Weiterentwicklung und all die vielen Erweiterungen, die es mittlerweile gibt.

[Union]

Nun ja, genau wie Delphi sollte man auch ADS regelmäßig updaten.

[Der schöne Günther]

Klar, im Delphi-Forum muss man etwas vorsichtiger sein, ab wann man ein Softwareprodukt als "tot" bezeichnen kann. Aber das Ding ist es doch wirklich so etwas von. So schade es ist.

Seit die Jungs von SAP gekauft wurden hat sich leider praktisch nichts mehr getan, und mittlerweile wurden auch alle Spuren von der SAP-Homepage beseitigt. Alte Links, Forenbeiträge und Dokumente geben nur noch 404-Fehlermeldungen. Das Ding ist bis heute nicht für Windows 10/Server 2016 zertifiziert, und die sind ja erst seit Sommer 2015 draußen. Zeitgleich werden die alten Versionen nicht mehr unterstützt, ist nicht Version 10 schon rausgeflogen?

Es ist schade drum, aber alleine bei den Verrenkungen die man machen muss um das Ding überhaupt zu kaufen oder einen Vertriebspartner dafür zu finden sollten eigentlich schon alle Alarmglocken schrillen.

Als Ansprechpartner für bestehende Systeme scheint es noch
- Joachim Dürr (auch hier im Forum aktiv)
- Hakan Haslaman
zu geben.



Um die Frage zu beantworten: Ja, wir haben es vereinzelt noch in Software drin. Aber es wird dort auch nicht mehr lange bleiben und wird ersetzt.

[Frickler]

Nicht nur Version 10, auch Version 11 ist rausgeflogen. Und Version 12, veröffentlicht Anfang 2016, hat ein paar unangenehme Bugs. Wir haben vor einigen Jahren alles von BDE auf ADS umgestellt und fragen uns jetzt, ob das wirklich der beste Schritt war...

[bernau]

Zitat:

Zitat von Frickler (Beitrag 1361664)

Nicht nur Version 10, auch Version 11 ist rausgeflogen. Und Version 12, veröffentlicht Anfang 2016, hat ein paar unangenehme Bugs. Wir haben vor einigen Jahren alles von BDE auf ADS umgestellt und fragen uns jetzt, ob das wirklich der beste Schritt war...

Bei mir genau so. :-(

Allerdings haben wir schon vor 15 Jahren umgestellt.

[Bernhard Geyer]

Zitat:

Zitat von Frickler (Beitrag 1361664)

Nicht nur Version 10, auch Version 11 ist rausgeflogen. Und Version 12, veröffentlicht Anfang 2016, hat ein paar unangenehme Bugs. Wir haben vor einigen Jahren alles von BDE auf ADS umgestellt und fragen uns jetzt, ob das wirklich der beste Schritt war...

Wer weiß ob die Alternativen auch heute noch existieren.
Am besten ist es immer wenn man sowas DBMS-Neutral entwickelt umd in einen solchen Fall relativ einfach wechseln zu können.

Wir sind auch vor ca. 15 Jahren auf ADS (LocalServer) gewechelt da die Lösung davor noch viel schlechter.
Mittlerweile ist auch ADS schon einige Jahre Geschichte (u.a. wegen Unicode).

[RSF]

Ich habe aktuell eine Anwendung mit ADS 12 verkauft.
Es ist nach wie vor kein Problem ADS bei SAP zu erwerben (durch Partnervertrag).
Auch ein Download der aktuellen Version 12 bei SAP ist möglich, aber sehr versteckt und nur mit ein Login.
Nebenbei habe ich mit meinem Ansprechpartner bei SAP über aktuelle Lage und Zukunft gesprochen. Ergebnis ist ernüchternd.
„Das Problem mit ADS und aktueller Delphi Version ist bekannt…..“
So werde ich vorsichthalber meine seit über 10 Jahren gewachsene Anwendung wohl Grundlegend überarbeiten müssen. Mein Favorit ist Postgres. Ein guter Grund zum Aufräumen alter Methoden.
Ich würde mich aber eher freuen wenn SAP den ADS und die Delphi-Komponenten zeitnah aktualisieren würde.:lol:

[Der schöne Günther]

Ich würde die Komponenten (bunte Vierecke aufs Formular ziehen) nicht überbewerten. Alternativ hat FireDAC eine gute Einbindung von ADS sodass man die Komponenten nicht selber kompilieren muss.

Nur die Tatsache dass man die Komponenten für alles nach Seattle selber kompilieren muss würde mich alleine nicht so sehr beunruhigen.


Aber eher wie lange die neuen Entwickler in Fernost gebraucht haben um zu verstehen dass die Komponenten ab XE8 nicht mehr funktionierten da im Quellcode lustig eine TList auf eine TList<T> hard-gecastet wurde. Und der Bugfix dann erst einmal für jedes Bewegen des Cursors eine neue TList anlegte und nie freigab (oder so ähnlich). Das, und die Tatsache dass nach dem Umzug auf SAP.com später so ziemlich alle Hinweise dass das Produkt jemals existiert hat entfernt wurden.

[Frickler]

Zitat:

Zitat von Der schöne Günther (Beitrag 1361731)

Ich würde die Komponenten (bunte Vierecke aufs Formular ziehen) nicht überbewerten. Alternativ hat FireDAC eine gute Einbindung von ADS sodass man die Komponenten nicht selber kompilieren muss.

Der "One size fits it all" Ansatz bei FireDAC kann aber gerade bei ADS nicht alles bieten, was die nativen Komponenten können. Etliche Aufgaben lassen sich gerade nicht in SQL erledigen, sondern Du musst z.B. AEPs (Advantage Extended Procedures) nutzen, die man von TAdsQuery aus aufrufen kann. Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt? Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

[hoika]

Hallo,

Zitat:

Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt?

Schon der Erzeuger der Tabelle, genauer des Tabellennamens sollte gesteinigt und gefedert werden!

Und das meine ich Ernst! *Ofen anzünd*

[Bernhard Geyer]

Zitat:

Zitat von Frickler (Beitrag 1361737)

Etliche Aufgaben lassen sich gerade nicht in SQL erledigen, sondern Du musst z.B. AEPs (Advantage Extended Procedures) nutzen, die man von TAdsQuery aus aufrufen kann. Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt? Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

Dafür hat jedes DBMS ein Administrations-Tool. Das brauch ich in den wenigsten Fällen in der eigenen Anwendung.

[hoika]

Hallo,

Zitat:

Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

Bei MS-SQL geht das mit den Sonderzeichen ...

[Frickler]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1361742)

Zitat:

Zitat von Frickler (Beitrag 1361737)

Etliche Aufgaben lassen sich gerade nicht in SQL erledigen, sondern Du musst z.B. AEPs (Advantage Extended Procedures) nutzen, die man von TAdsQuery aus aufrufen kann. Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt? Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

Dafür hat jedes DBMS ein Administrations-Tool. Das brauch ich in den wenigsten Fällen in der eigenen Anwendung.

Das kannst Du machen, wenn Du der einzige Anwender bist. Bei Kunden muss sowas automatisch ablaufen können.

@Hoika ich halte das auch für nen Bug. Denn ansonsten kann man mit solchen Tabellen mit SQL wirklich alles machen. Alles außer "Alter Table"...

[RSF]

Zitat:

Zitat von Frickler (Beitrag 1361737)

Der "One size fits it all" Ansatz bei FireDAC kann aber gerade bei ADS nicht alles bieten, was die nativen Komponenten können. Etliche Aufgaben lassen sich gerade nicht in SQL erledigen, sondern Du musst z.B. AEPs (Advantage Extended Procedures) nutzen, die man von TAdsQuery aus aufrufen kann. Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt? Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

Kann ich voll bestätigen. Ich habe versucht ADS DB mit FireDAC anzusteuern und bin enttäuscht.
Für kleinere Adressdatenbanken möge das reichen, aber bei eine komplexen DB mit Administration nicht mehr.
Einige Funktionen fehlen schlichtweg andere sind umständlich. Klar man kann es nicht jedem recht machen.
Dafür sind (waren) eben die nativen Komponenten von ADS da.
z.B
CREATE DATABASE "Datenbankxy.add" ist nicht mit FireDAC und ADS möglich
AdsConnection1.DDVersionMajor ( bzw. Minor) Funktion ist auch nicht vorhanden, nur über SQL Systemtabelle möglich

Ich hatte nach unendlichen Stunden, mit zum Teil frustrierenden Ergebnissen, einfach keine Lust mehr mein altes ADS-Projekt an Delphi Berlin (mit FireDAC) anzupassen. Es wird jetzt einfach mit Delphi XE weitergepflegt und parallel dazu auf Delphi Berlin und auf Basis von Postges neu entwickelt.

[Bernhard Geyer]

Zitat:

Zitat von Frickler (Beitrag 1361765)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1361742)

Zitat:

Zitat von Frickler (Beitrag 1361737)

Etliche Aufgaben lassen sich gerade nicht in SQL erledigen, sondern Du musst z.B. AEPs (Advantage Extended Procedures) nutzen, die man von TAdsQuery aus aufrufen kann. Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt? Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

Dafür hat jedes DBMS ein Administrations-Tool. Das brauch ich in den wenigsten Fällen in der eigenen Anwendung.

Das kannst Du machen, wenn Du der einzige Anwender bist. Bei Kunden muss sowas automatisch ablaufen können.

Das Beispiel war aber sehr gekünstelt. Diesen habe ich so nicht.
Und die normalen Strukturänderungen machen wir ja auch Programmtechnisch.

Aber wenn DDL nur über die Spezialkomponenten möglich wäre dann war das schon eine ziemliche Einschränkung des DBMS

[p80286]

Zitat:

Zitat von hoika (Beitrag 1361738)

Hallo,

Zitat:

Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt?

Schon der Erzeuger der Tabelle, genauer des Tabellennamens sollte gesteinigt und gefedert werden!

Und das meine ich Ernst! *Ofen anzünd*

Wo ist das Problem? Access kann das problemlos, erst als (vor einigen Jahren) die Anwendung auf den MS-Sqlserver portiert wurde, hat es ein wenig Mehrarbeit gekostet. Das schlimmste war, dem Benutzer klar zu machen, daß Umlaute in Tabellennamen eben nicht vom MSSql-Server unterstützt wurden.
:wall:


Gruß
K-H

[joachimd]

Zitat:

Zitat von Frickler (Beitrag 1361737)

Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt? Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

Sorry für die harte Kritik ... aber so einen Sch... macht man auch nicht. Objektnamen mit Umlauten anzulegen ist per Design schon ein Bug, auch wenn es möglich ist.

[joachimd]

Zitat:

Zitat von RSF (Beitrag 1361768)

Ich hatte nach unendlichen Stunden, mit zum Teil frustrierenden Ergebnissen, einfach keine Lust mehr mein altes ADS-Projekt an Delphi Berlin (mit FireDAC) anzupassen. Es wird jetzt einfach mit Delphi XE weitergepflegt und parallel dazu auf Delphi Berlin und auf Basis von Postges neu entwickelt.

Wie man die ADS Komponenten in 10.1. Berlin nutzt, habe ich schon vor fast einem Jahr gezeigt: https://www.jd-engineering.de/using-...i-10-1-berlin/. Klar ist die Option FireDAC verführend, aber das Framework beherrscht halt nur den kleinsten gemeinsamen Nenner.

[RSF]

Zitat:

Zitat von joachimd (Beitrag 1361813)

Wie man die ADS Komponenten in 10.1. Berlin nutzt, habe ich schon vor fast einem Jahr gezeigt: https://www.jd-engineering.de/using-...i-10-1-berlin/. Klar ist die Option FireDAC verführend, aber das Framework beherrscht halt nur den kleinsten gemeinsamen Nenner.

Habe ich auch probiert. Habe es auch in Berlin 10.1 installieren können und funktioniert auch. Bis auf, dass die Icons der Komponenten nur als Standard-Icon angezeigt werden. Sowie bei Erzeugung meiner Anwendung unter 64Bit, es zur Fehlermeldung gekommen ist.

[dcc64 Fataler Fehler] adscnnct.pas(293): F2063 Verwendete Unit 'ace.pas' kann nicht compiliert werden

[joachimd]

Zitat:

Zitat von RSF (Beitrag 1361826)

[dcc64 Fataler Fehler] adscnnct.pas(293): F2063 Verwendete Unit 'ace.pas' kann nicht compiliert werden

Das liegt wahrscheinloich daran, dass für die 64-Bit-Windows Plattform der Bibliothekspfad nicht angerpasst wurde. Das Package wurde unter 32Bit compiliert und installiert.
"Tools -> Optionen -> Umgebungsoptionen -> Delphi-Optionen -> Bibliothek" suchen, bei "Ausgewählte Plattform" sicherstellen, dass "64-Bit-Windows" ausgewählt ist, dann bei "Bibliothekspfad" den Pfad zu den Quellen hinzufügen (zB C:\Program Files (x86)\Advantage 12.0\TDataset\Source).

[Bernhard Geyer]

Zitat:

Zitat von p80286 (Beitrag 1361785)

... daß Umlaute in Tabellennamen eben nicht vom MSSql-Server unterstützt wurden.

Du meinst wohl das eure Anwendung das nicht unterstützt.
Hab gerade im 2016er ein Tabelle "Tabelle_äöü" mit Feld "äöü angelegt.
Funktioniert prächtig.

[Bernhard Geyer]

Zitat:

Zitat von joachimd (Beitrag 1361810)

Sorry für die harte Kritik ... aber so einen Sch... macht man auch nicht. Objektnamen mit Umlauten anzulegen ist per Design schon ein Bug, auch wenn es möglich ist.

Jedes vernünftige DBMS hat heutzutage kein Problem mehr mit Sonderzeichen in Tabellen/Feldnamen.
Ob man sowas in der eigenen Anwendung zulässt ist ein eigenes Thema.

[RSF]

Zitat:

Zitat von joachimd (Beitrag 1361843)

Das liegt wahrscheinloich daran, dass für die 64-Bit-Windows Plattform der Bibliothekspfad nicht angerpasst wurde. Das Package wurde unter 32Bit compiliert und installiert.
"Tools -> Optionen -> Umgebungsoptionen -> Delphi-Optionen -> Bibliothek" suchen, bei "Ausgewählte Plattform" sicherstellen, dass "64-Bit-Windows" ausgewählt ist, dann bei "Bibliothekspfad" den Pfad zu den Quellen hinzufügen (zB C:\Program Files (x86)\Advantage 12.0\TDataset\Source).

Habe nachgeschaut Bibiothekspfad ist in Plattform 32- und 64bit entsprechend gesetzt.
(c:\program files (x86)\advantage 11.10\tdataset\delphi101berlin\win32\source)
(c:\program files (x86)\advantage 11.10\tdataset\delphi101berlin\win64\source)


[dcc64 Fataler Fehler] adscnnct.pas(293): F2063 Verwendete Unit 'ace.pas' kann nicht compiliert werden

Ich gebe es auf:(

[Rollo62]

Kann mich mal jemand aufklären warum SAP so an ADS interessiert war (ist) ?
Das ADS war doch ziemlich Delphi-lastig, so hatte ich das immer eingeschätzt.

Rollo

[Union]

Zitat:

Zitat von Rollo62 (Beitrag 1361852)

Kann mich mal jemand aufklären warum SAP so an ADS interessiert war (ist) ?
Das ADS war doch ziemlich Delphi-lastig, so hatte ich das immer eingeschätzt.

Rollo

Sieh mal z.B. hier

[p80286]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1361846)

Zitat:

Zitat von p80286 (Beitrag 1361785)

... daß Umlaute in Tabellennamen eben nicht vom MSSql-Server unterstützt wurden.

Du meinst wohl das eure Anwendung das nicht unterstützt.
Hab gerade im 2016er ein Tabelle "Tabelle_äöü" mit Feld "äöü angelegt.
Funktioniert prächtig.

2016 Jaaaa, es ist schon etwas her, so 2009/2010, da hat's dafür noch Haue gegeben.

Gruß
K-H

[joachimd]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1361847)

Jedes vernünftige DBMS hat heutzutage kein Problem mehr mit Sonderzeichen in Tabellen/Feldnamen.
Ob man sowas in der eigenen Anwendung zulässt ist ein eigenes Thema.

Solange das Encoding stimmt auch alles kein Problem. Aber weh, man hat dann die deutsche DB im Auslandseinsatz, wo es die Umlaute eben nicht gibt. Wie heisst es so schön: ich habe schon Pferde kotzen sehen ;)

[joachimd]

Zitat:

Zitat von Rollo62 (Beitrag 1361852)

Kann mich mal jemand aufklären warum SAP so an ADS interessiert war (ist) ?
Das ADS war doch ziemlich Delphi-lastig, so hatte ich das immer eingeschätzt.

SAP weiss/wusste nichts von ADS ... genausowenig wie Sybase zuvor. Und das mit Delphi-lastig ist nicht so ganz richtig. Delphi ist zwar immer schon ein großer Markt gewesen, die Wurzeln liegen aber in den Xbase-Sprachen (Clipper, VO, Xbase++, DBase, FoxPro, ...).

[mjustin]

Zitat:

Zitat von joachimd (Beitrag 1361882)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1361847)

Jedes vernünftige DBMS hat heutzutage kein Problem mehr mit Sonderzeichen in Tabellen/Feldnamen.
Ob man sowas in der eigenen Anwendung zulässt ist ein eigenes Thema.

Solange das Encoding stimmt auch alles kein Problem.

Huch? Wird für Strings in den Metadaten denn nicht Unicode verwendet? (Würde ich anno 2016 eigentlich erwarten)

[Der schöne Günther]

Trotz diesen leicht negativen Vibes hier würde ich trotzdem gerne anmerken dass wir mit dem Advantage Server (hauptsächlich local) immer zufrieden waren (und sind), auch die Doku hat nie Grund zur Beanstandung gegeben. Einzig die (z.B. im Vergleich zu Sqlite) fehlenden Transaktionen fehlen schmerzlich.

[Rollo62]

@Union

Große Firma ... große Probleme :stupid:

Wer so viel Geld für möglichen KnowHow-Gewinn hinblättert, der hat entweder zuviel Spielgeld übrig, oder scheint das KnowHow auch wirklich zu brauchen.

Schade das bei diesen Managementspielchen immer Einige auf der Stecke bleiben.

Rollo

[joachimd]

Zitat:

Zitat von mjustin (Beitrag 1361884)

Huch? Wird für Strings in den Metadaten denn nicht Unicode verwendet? (Würde ich anno 2016 eigentlich erwarten)

Nein ... denn dann müsste der ADS wie viele andere Systeme bei jeder Version komplett andere DB Strukturen aufbauen - und das war ja immer der große Vorteil: ohne Migration rückwärtskompatibel bis zur Version 3 (das war die erste echte Version).

[RSF]

Zitat:

Zitat von Rollo62 (Beitrag 1361888)

@Union

Große Firma ... große Probleme :stupid:

Wer so viel Geld für möglichen KnowHow-Gewinn hinblättert, der hat entweder zuviel Spielgeld übrig, oder scheint das KnowHow auch wirklich zu brauchen.

Schade das bei diesen Managementspielchen immer Einige auf der Stecke bleiben.

Rollo

Wer weis .. vielleicht lesen auch für den ADS verantwortliche SAP Leute mit.
Es gab früher (vor SAP) viele die den ADS geschätzt haben.
Nicht nur wegen der Werbung in einigen Fachzeitschriften.
Die Kernfrage aber bleibt „ Wie sieht die Zukunft von ADS aus“

PS: Ja, ich habe schon bei SAP telef. nachgefragt. Leider ohne konkrete Aussage. Lapidar „Das Problem ist bekannt“

[trifid]

Hallo,
>Die Kernfrage aber bleibt „ Wie sieht die Zukunft von ADS aus“
Oder, um eine Ableitung von Geschehen zu ziehen - was hat SAP mit CrystalReport gemacht?
Man muss wissen, dass der ADS als Plattform für die mobilen Lösungen von SAP dienen sollte.
Mittlerweile ist die Komminkation über einer direkten Onlineverbindung via direkten RFC-Call oder ein Web-Services von SAP.
Deswegen stellt man sich die Frage, ob die Daten asynchron (vor)gehalten halten müssen.
SAP denkt nicht über eure Anwendungen nach, sondern welchen Vorteil sie selber haben.

[Rollo62]

Zitat:

SAP denkt nicht über eure Anwendungen nach

Und genau deswegen denke ich auch nicht über SAP nach.
Es gibt auch schöne freie DB's, also ich würde unter gg. Umständen schnellstmöglich umstellen, falls mich nicht ein Kunde zu ADS zwingt.

Rollo

[MichaelT]

Crystal Reports: SAP hat ein Reporting Tool gebraucht und ja man kann damit Berichte bauen. Mit klassischem SAP gab es damals nur in ABAP programmierte Berichte (ein Programm das den Bericht schreibt ohne viel Formatierung wie am Nadeldrucker).

Es gab mal eine andere Lösung fürs Reporting die ganz gut war und vermutlich gibt es pro Modul eine eigene Lösung fürs Drucken oder wie auch immer, kann mich nicht mehr erinnern - oder will das zumindest nicht mehr. CR war auf jeden Fall Fortschritt damals. SAP hat selbst den Batchmonitor zugekauft. Die sind eher ganz gut wenn es darum geht ganze Applikationsmoloche über 2 Jahre fast schlüsselfertig (mittlereweile bspw. SAP CRM in der heutigen Fassung) hinzustellen. Das erste SAP CRM war ein paar Dialoge die um so 2 Mio. wurden zugekauft (gar nichts, hat nie jemand gebraucht). Aber wenn die SAP mal weiß die Kunden wollen, dann ... geht was - wie bei IBM.

IBM hat begonnen alles zusammenzukaufen und SAP hat den Rest im Reporting und BI Tool Bereich zusammengekauft. Business Objects, Teils Crystal und noch ein paar andere Tools die ganz gut waren aber klammheimlich verschwanden, da oh große Überraschung in Konzernen die User nicht mit Excel rumbastelten und Desktop BI Portale wollten ...

Die List der Übernahmen steht auf Wikipedia.

---

Wobei wenn jemand wirklich was halbwegs sinnvolles sucht gibt es Lösungen aus Stuttgart (Patrick Theobald).
Theobald Software
Ist ein ganz ein honoriger Mensch.


SAP tut immer irgendetwas und am Ende bleibt wenig übrig.

Von Sybase haben sie benutzt den Column Store und eine Middleware für Mobiles ... Das Konzept ist untergegangen. Die Middleware selbst war ganz gut. Die wollten so ala Oracle zu Beginn und auch SAP zur Zeit von frühen R3 Versionen. Jeder User bekommt ein Schema und die Phone Daten (damals noch Mobiles/Handys und keine SmartXYZ) sind werden dorthin repliziert. Im R/2 wurde die GUI Daten noch auf Files geschrieben und hernach reingesynced auf den zentralen Datenbestand (Batch - Verbuchungsprozesse).

btw. diese Middleware kommt von einem Schuppen in Deutschland der sogar ein 'MIDAS Replacement' hatte, bevor dieses Unternehmen von Sybase wurde übernommen ... so um 2k herum - zur Zeit von ASP Express (Marotz). Ich kann mich an den Namen nicht mehr erinnern.

Ob ADS mehr ist als eine Laus im Pelz oder so gesehen wird. Es gab mal so einen SAP CEO (nicht der Plattner) der einfach gesagt hat SAP wird Software Entwickler und verkauf Software (Zur Zeit von SDN). SAP hat mit GUI an sich nicht soviel am Hut. Die sind daran nicht wirklich interessiert. Die hätten es an sich mehr schon immer mit reiner Business Logik gehabt.

Zitat:

Zitat von trifid (Beitrag 1361914)

Hallo,
>Die Kernfrage aber bleibt „ Wie sieht die Zukunft von ADS aus“
Oder, um eine Ableitung von Geschehen zu ziehen - was hat SAP mit CrystalReport gemacht?
Man muss wissen, dass der ADS als Plattform für die mobilen Lösungen von SAP dienen sollte.
Mittlerweile ist die Komminkation über einer direkten Onlineverbindung via direkten RFC-Call oder ein Web-Services von SAP.
Deswegen stellt man sich die Frage, ob die Daten asynchron (vor)gehalten halten müssen.
SAP denkt nicht über eure Anwendungen nach, sondern welchen Vorteil sie selber haben.

[Frickler]

Zitat:

Zitat von trifid (Beitrag 1361914)

Hallo,
>Die Kernfrage aber bleibt „ Wie sieht die Zukunft von ADS aus“
Oder, um eine Ableitung von Geschehen zu ziehen - was hat SAP mit CrystalReport gemacht?
Man muss wissen, dass der ADS als Plattform für die mobilen Lösungen von SAP dienen sollte.

Sicher? Die Lösung für Mobile Plattformen ist doch iAnywhere bzw. Sybase ASA. Das ist zwar auch ne "kleine" Datenbank, hat aber ansonsten nichts mit ADS zu tun. ADS ist ein Server für ein von FoxPro (dBase) abgeleitetes Datenbankformat, mit etlichen Kompatibilitätsfunktionen für den guten alten ISAM-Zugriff, aber halt auch SQL-Zugriff.

[Pfaffe]

Info - ADS 12 Service Pack 2:
https://blogs.sap.com/2017/12/01/adv...-for-download/

[Frickler]

Zitat:

Zitat von Pfaffe (Beitrag 1388662)

Info - ADS 12 Service Pack 2:
https://blogs.sap.com/2017/12/01/adv...-for-download/

Mal in die Release Notes geschaut? Dafür, dass das Service Pack mehr als ein Jahr lang angekündigt war (immer hieß es "demnächst"), wurde recht wenig geändert. Immerhin scheinen die CAST/Convert Bugs mit negativen und ganzen Zahlen (*) verschwunden zu sein. Delphi Berlin wird jetzt unterstützt - wow - und das haben sie auf exakt dem gleichen Weg gemacht wie Joachim Dürr auf seinem Blog beschreibt. Der beschreibt dort auch, wie man um einen ziemlich blöden Bug der ADS Komponenten unter Tokyo drumrumkommt. Achja, und Windows 10 bzw. Server 2016 wird unterstützt, zumindest in der Version 1607.
In dem "tollen" Forum hat schon einer den ersten Bug im neuen SP gepostet (den er vor 2 Jahren gemeldet hatte...)


--
(*) z.B. SELECT Convert(ABS(2016), SQL_CHAR) FROM system.iota ergab 46565812772