Ich weiß nicht, wo ich es hinposten soll, daher einfach mal bei mir zu hause.

Gibt es kein ALTER - Command um den Typen einer Spalte zu ändern?

Es geht tatsächlich nicht. Daher der Workaround

dbforums.com/t1051977.html

Jepp, danke, so machen die das. Der Inhalt muss übrigens nicht futsch sein, weil du den "rübercasten" kannst.

Naja, bei einem Design-Tool kann ich wohl nicht verlangen, dass man sich das vorher überlegt ...

Jo, das hatte ich dann auch irgendwann gefunden. Es soll bisher ein reines PostgreSQL Framework sein. Aber ich bereite das schon entsprechend vor ...

Du kannst übrigens von ziemlichen Glück sprechen, dass ich nach "MS" noch weitergelesen habe. Ich gehe jetzt mal meine Augen mit Sagrotan auswaschen. So etwas kann übel enden ...

Jo, danke, hat mir auch jemand bei heise gesagt, nachdem ich es überlesen hatte. Naja, ich werde es erstmal aus Gründen der Kompatibilität wie in 7.x implementieren. Viel anderes wird die 8.0er auch nicht machen.

Naja, ich habe bisher nur mit a.C.c.E.S.s als DBMS zu tun gehabt. Solange man im Abfragebeereich bleibt, nehmen die sich ja alle mehr oder weniger nichts. Durch das Framework kam ich jetzt halt mehr in den Design-Bereich. Da musste ich schon einiges nachsuchen. Am meisten haben mir die SQL99 (?) - konformen Information Schemas geholfen.

Aber ich glaube, dass ich jetzt in dieser Beziehung auf einem ganz guten Weg bin. Das Ding wächst und wächst und vor allem: Es wächst immer schneller. Ich mach mich jetzt nochmal an die Constraints und References. Dnn ist das, was man sourcecodefrei machen kann so ziemlich erledigt. Danach muss das an möglichst viele better Testa, um die ganzen Fälle, die ich nicht berücksichtigt habe, bugfrei hinzubekommen.

Dann schauen wir mal, wie es weitergeht.

Ich versuche es soweit wie möglich an den SQL-Standard anzulehnen. Ich gehe auch davon aus, dass die libs ähnlich sein werden.

Derzeit ziehe ich eine Zwischendecke ein, die ein "String - to - Server" Interface einzieht und sich von den angebotenen Methoden her an SQL orientiert. Dies wäre dann (wohl, Überraschungen gibt es immer) sozusagen der "Treiber".

Der Hintergrund ist aber eigentlich, dass ich einfach 1298712397312987 Mal vergessen habe Abfrageergebnisse wieder freizugeben und derlei Späßken, die dem Speicher nicht gerade gut tun, Ich muss ohnehin alles komplett noch einmal durchchecken. (Einmal habe ich schlicht vergessen einen dealloc zu einer Klasse zu schreiben. :-))

Eine einfache DB für deine eigene, private App bekommst du ja mit CoreData und MySQL. Mein Hintergrund ist ein anderer. Ich wollte schon lange meine Anwaltssoftware auf OS X portieren. Hierzu benötige ich aber ein stabiles und anständiges DBMS, die netzwerkfähig ist. Einer aus dem Forum brachte mich auf PostgreSQL.

Ob das mit anderen DBMS geht, ist zweifelhaft. Beispiel:
Ich habe zuweilen Abfragen in Abfragen:

(Das kapsele ich gerade oo als Zwischendecke.)

Nicht jede Lib/DBMS bietet wohl solche verschachtelten Results an. Dann müßte man also glech auf "höherer" Ebene selbst Zwischenergebnisse speichern usw. Das werde ich nicht unterstützen.

Wenn ich mir dein Codebeispiel dazu anschaue finde ich es recht ähnlich der Philosophie von gängigen Frameworks wie ODBC oder JDBC. Worin besteht denn der wesentliche Vorteil eines neuen Frameworks?

Für PostgreSQL gibt es kein Objective-C Framework. Der Vorteil liegt darin, dass ich das strikt auf Cocoa/oC setze und Bindings anbiete. Als "Client" des Frameworks schreibe ich gerade ein Tool zum Erstellen von PostgreSQL Datenbanken, ohne dass ich Sourcen eingeben muss. Einfach im IB zusammenstecken.

Ebenso sieht es mit normalen Clients aus. Du legst da deine TableViews in ein Fenster und bindest die. Wenn du den IB beherrschst hast du so etwas wie einen Access-Forumlargenerator. Sourcen müssen nicht erstellt werden.

Ich kann mir vorstellen, das es ein ziemlicher Aufwand ist, dieses zu erstellen

Der Vorteil ist eben, dass niemand, der damit einen Client schreibt, diese Mühe erneut machen muss. Er steckt nur noch zusammen.

Ich wollte mir dein Framework auch mal genauer anschauen, aber irgendwie bin ich zu blöd in dem Thread (Erstes pre-alpha) eine Möglichkeit zu finden es zu laden.

Ja, das wundert mich nicht. Ihc hatte einfach mein Projektverzeichnis as is hochgeladen. Da musste man also händisch Anpassungen vornehmen. Das nächste wird "richtig" als eigenes Framework mit Installtionsanweisung gemacht. Das war halt nachts nach getaner Arbeit - schrieb ich ja auch im Thread.

Ich wollte mir dein Framework auch mal genauer anschauen, aber irgendwie bin ich zu blöd in dem Thread (Erstes pre-alpha) eine Möglichkeit zu finden es zu laden.

SubQueries sind nie ein Problem, da sie ja "DB-intern" bleiben. Du bekommst nur _ein_ Gesamtergebnis geliefert. Ich habe von jemanden gehört, dass es DBMS/Libs gibt, die das nicht unterstützen. Ich verlasse mich halt darauf. Wenn das fast immer geht: Umso besser!

BTW: Sagrotan ist alle Ich bin jetzt auf Domestos umgestiegen. ;-)

Jo, habe ich auch schon dran gedacht. Dazu müsste ich mich aber erst einmal in das ODBC-API einlesen und schauen ob das geht ...

Was empfiehlst du denn?

BTW: Die Bindings machen erst richtig Spaß, wenn ich eine Brücke zu Trigger habe. Life-Bindings über die Datenbank einmal um die Welt ...

Öhm, um es gleich vorwegzunehmen. Mir ist libiodbc bekannt. Ich habe bloß nie irgendwelche Header für ein API gefunden. Vielleich bin ich einfach zu blöde?

na super! Also bin ich doch blöde oder wenigstens blind ...

Na, das schaue ich mir noch _heute_ an.

Hmm, die scheinen das ähnlich zu machen und bieten zudem Kapsleung einiger Angelegenheiten, die ich zu Fuß machen musste.

Das sieht _sehr_, _sehr_ gut aus.

Vielen Dank!