Seite 2 von 3

Verfasst: 22.06.2006 22:24
von ts-soft
@mike41 und @mk-soft

Wie ihr schon bemerkt hab, funktioniert die PBOSL_ExDataBase unter PB4
nicht mehr, bzw. ich bekomme sie zwar kompiliert, aber beim testen nur
Fehlermeldungen.

Wie wäre es, wenn Ihr euch zusammen tut und Mithilfe eurer Proceduren
eine neue ExDatabase für PBOSL entwickelt. Syntaxgleiche Proceduren
sind zwar erwünscht, aber nicht unbedingt erforderlich.

Mir fehlt leider die Zeit und von SQL hab ich keinen blassen Schimmer :wink:

Sagt Bescheid, per PM oder hier, was ihr von meinem Vorschlag haltet.

Gruß
Thomas

Verfasst: 23.06.2006 09:02
von Rings
Richtig Thomas,
denn es ist nicht im Sinne
das nur einer alleine (so hab ich den Eindruck)
die ganze Arbeit bei der Konvertierung (etc.)
für die PBOSL 4 macht.
Also , Leutz, die PBOSL braucht euch !!
Gebt der Community was zurück......

Verfasst: 23.06.2006 09:40
von mike41
Na klar gern, vier Augen sehen mehr (sorry sechs trag eine Brille 8) )

Verfasst: 23.06.2006 10:03
von Karl
Soll das Ding dreigeteilt sein und aus vorhandenen PB-Befehlen erstellt werden?

Datenbankoperationen (erstellen, löschen, reparieren, komprimieren)
Tabellenoperationen (anlegen, löschen, erweitern)
Datensatzoperationen (anlegen, löschen, verändern, finden)

Die Schnittstelle dann möglichst einfach und intern mit SQL-Befehlen?

Beispiel:

Code: Alles auswählen

Procedure.s Find(Tabelle.s, Feld.s, Wert.s)
...
EndProcedure
Gruß Karl

Verfasst: 23.06.2006 19:04
von mike41
Ich denke eher aus zwei.

Datenbank- und Tabellenoperationen zusammen, da z.B. Paradoxdateien
nur aus Tabellen bestehen. Macht irgendwie Sinn.

Und eine.Lib aus eine Art Recordset.

-ADD
-DELETE
-MOVEFIRST
-MOVENEXT
-MOVEPREVIOUS
-MOVELAST
-FIND
-FIELDS(VALUE)
-ABSOLUTEPOSITION
-BOOKMARK ect.

Sie wird sehr einfach gehalten und ohne SQL gehts ja nicht. Nur ist
die Frage ob PB befehle dafür genommen werden.
Die Vergangenheit hat gezeigt, dass mit jeder neuen Version Veränderungen auftreten. Siehe ExDatabase.

Code: Alles auswählen

Procedure RecordsetNext ()
OpenLibrary(0,"msorcl32.dll")
CallFunction(0,"SQLExtendedFetch",hstmt.l, SQL_FD_FETCH_NEXT, irow.l, pcrow.l,SQL_FD_FETCH_ABSOLUTE)
EndProcedure

Verfasst: 23.06.2006 23:47
von ts-soft
mike41 hat geschrieben: Und eine.Lib aus eine Art Recordset.

-ADD
-DELETE
-MOVEFIRST
-MOVENEXT
-MOVEPREVIOUS
-MOVELAST
-FIND
-FIELDS(VALUE)
-ABSOLUTEPOSITION
-BOOKMARK ect.
Also Recordset finde ich schon mal sehr gut!
mike41 hat geschrieben: Sie wird sehr einfach gehalten und ohne SQL gehts ja nicht. Nur ist
die Frage ob PB befehle dafür genommen werden.
Die Vergangenheit hat gezeigt, dass mit jeder neuen Version Veränderungen auftreten. Siehe ExDatabase.
Wenn es mit reiner API gehen würde, wäre es schon besser. Weil nach
Linux übertragen kann man es wohl kaum (vermute ich mal).
Wenns OS abhängig ist, dann möglichst API.

Und eine einfach Nutzung für Leute ohne SQL-Kenntnissen halte ich auch
für wichtig, so das die Leute mit SQL-Kenntnisse auf ihre kosten kommen,
aber auch Laien einfache Adressdatenbanken erstellen und nutzen können.

Wenn ihr das schafft, würde mich, und wahrscheinlich die ganze PB-Welt,
das erfreuen
:allright:

Verfasst: 24.06.2006 09:34
von mike41
Wenn es mit reiner API gehen würde, wäre es schon besser. Weil nach
Linux übertragen kann man es wohl kaum (vermute ich mal).
Wenns OS abhängig ist, dann möglichst API.
mitnichten, unter Linux existiert die UnixODBC, ist eine Art Wrapper,
mit den selben Befehlen. Nur die Umsetzung ist mir noch schleierhaft.

Nur mit Api Befehlen wäre zu umfangreich. Einige Hauptbefehle die
sich nicht ändern werden (Hoffe ich jedenfalls) wie z.B. OpenDatabase()
,GetDatabseString oder DatabaseQuery() sind schon sehr hilfreich.
Die aber nicht wegfallen werden.(man will ja nicht den Spass nehmen :wink: )

Es soll aber auch einfach werden für nicht SQLer stimmst? <)

Mfg Mike

Verfasst: 24.06.2006 10:17
von ts-soft
mike41 hat geschrieben: Es soll aber auch einfach werden für nicht SQLer stimmst? <)
jo, stimmst :wink:

Verfasst: 16.07.2006 11:57
von mike41
So Leutz!

Hab mal einen Versuch gestartet die DBInclude fertig zu stellen. Ist noch reiner PB Code da mir die Zeit fehlte.

Für Anregungen, Vorschläge und Kritik wäre ich sehr dankbar.

Ich hab ein paar Dateien zum ausführen in eine ZIP gepackt um es ein bischen verständlicher zu machen. :allright:

MfG Mike

http://people.freenet.de/mike.teesch/index.htm

Verfasst: 16.07.2006 13:27
von Kiffi
> Hab mal einen Versuch gestartet die DBInclude fertig zu stellen.

Super, dass Du am Ball geblieben bist! :D

> Ist noch reiner PB Code da mir die Zeit fehlte.

ist nicht schlimm. Seit PB4 (und der noch unzureichenden Unterstützung
durch TailBite) ist es momentan sogar von Vorteil, wenn Code als Includes
vorliegen. Manche Leute hier verwenden (aus nachvollziehbaren Gründen)
überhaupt keine Libraries. Mit der jetzigen Lösung würdest Du also ein
grösseres Publikum ansprechen.

> Für Anregungen, Vorschläge und Kritik wäre ich sehr dankbar.

ich habe mir den Code noch nicht en detail angeschaut, aber drei Vorschläge
hätte ich auf Anhieb:

1. Beim db_Connect() solltest Du auch #PB_Any als ersten Parameter
anbieten. #PB_Any ist eine Konstante mit dem Wert -1. Wenn dieser Wert
Deinem db_Connect() übergeben wird, so suchst Du die nächstfreie
Datenbanknummer selber aus und gibst sie an den Aufrufenden zurück.
Somit muss der Programmierer sich selber keine Gedanken um die
Vergabe der Datenbanknummer machen.

also, entweder so:

Code: Alles auswählen

If db_Connect(99, ...) ; Datenbanknummer ist 99
 [...]
 db_Disconnect(99, ...)
... oder so ...

Code: Alles auswählen

myDatabaseNumber = db_Connect(#PB_Any, ...) ; Datenbanknummer steht in myDatabaseNumber 
If myDatabaseNumber
 [...]
 db_Disconnect(myDatabaseNumber, ...)
2. Bitte entferne die MessageRequester aus Deinem Code. Fülle anstatt
dessen eine interne Variable LastMessage$ oder LastError$, die Du über
eine Funktion GetLastMessage.s() oder GetLastError.s() nach aussen
leitest. Es sollte dem Programmierer überlassen sein, in welcher Form und
in welcher Sprache er Fehler dem Anwender präsentiert.

3. Momentan muss man beim Disconnecten den Datenbanknamen mit
angeben. Wenn Du in Deinem Code diese Namen intern in Bezug auf die
Datenbanknummer mitspeichern würdest (beispielsweise in einer
LinkedList), könnte man sich diese Angabe sparen und das Fehlerpotential
reduzieren.

Ansonsten: Weiter so! :allright:

Grüße ... Kiffi