Autor | Thema: Korrigierte Betaversion zum Download! |
| Datum:26.08.02 11:35 
(rgh-soft@t-online.de) | |
Hallo,
zunächst mal ein Dank an alle Tester.
Ich hoffe die wesentlichen Probleme nun beseitigt zu haben!
Die Verschachtelung und die Verwendung von @&(0) sollte klappen und Umlaute in Prozedurnamen sollten auch dann keine Probleme mehr bereiten, wenn die Prozedur als Funktion aufgerufen wird.
BTW: Kleingeschriebene Umlaute in Namen von definierten Funktionen machten seit jeher Probleme ... ist nur niemandem aufgefallen, da man normalerweise keine verwendet.
Die neue Version gibt es an der bekannten Adresse:
http://www.profan2.de/download/xprofan.zip
Gruß
Roland
|
|
| Datum:29.08.02 10:59 
(rgh-soft@t-online.de) | |
Die aktuelle Version ist vom 28. August und kann auch Memofelder über 255 Zeichen per SQL korrekt auslesen.
Gruß
Roland
|
|
| Datum:30.08.02 01:02 
(IsNoMK@gmx.de) | |
Hallo,
ich wollte mal fragen in wieweit sich was in der Fehlerbehebung getan hat ? Neue Funktionen und Möglichkeiten sind natürlich toll, aber die ganzen Fehler machen mir doch manchmal das Programmieren ziemlich schwer. Allein bei der entwicklung beim Pathfinder bin ich über gut ein Dutzend Fehler von Profan gestolpert ! Allen voran natürlich Case/Casenot. Ich will nicht sagen das Profan schlecht ist, aber ich finde gerade bei einer Programmiersprache sollte Qualität vor Quantität kommen, wo du mir wahrscheinlich auch zustimmen wirst.
schöne Grüsse aus dem im Ausnahmezustand befindenden Berlin :),
Moritz
|
|
| Datum:30.08.02 12:25 
(rgh-soft@t-online.de) | |
Hallo Moritz,
natürlich bin ich bestrebt bei einer neuen Version alle bis dahin bekannten und nachvollziehbaren Fehler zu beheben. Das habe ich immer schon so gehalten. Das setzt allerdings vorraus, dass mir diese Fehler auch bekannt sind. Mit CASE und CASENOT sind mir zur Zeit keine Fehler mehr bekannt.
Also: Wenn es noch Fehler in Version 7.5 gibt (und die auch in der aktuellen Betaversion noch auftreten), bitte eine entsprechende Mail mit Beispielprogramm und aussagekräftiger Fehlerbeschreibung an mich. Das Beispielprogramm sollte nur den Fehler demonstrieren und nicht länger als etwa 30 Zeilen sein. Sollten externe Dateien oder DLLs benötigt werden, diese bitte mitsenden. (Anhänge, die größer als 500 kB sind, bitte vorher ankündigen.)
Gruß
Roland
|
|
| Datum:31.08.02 01:12 
(IsNoMK@gmx.de) | |
Hallo Roland,
ok, ich werd die mir bekannten Fehler mal mit der Beta testen und dir dann ggf. eine Mail schicken...
Moritz
|
|
| Datum:13.09.02 20:03 
(HJKramm@Web.de) | |
nun fein, das ist ja prima mit den memo-feldern...
läuft auch unter access.... sehr schön.....
aber wo bleibt die zweite odbc-schnittstelle ??
tabellen verbinden lokal/netz ist fuer mich wirklich dringend.
geht es ... oder nicht ??
|
|
| Datum:16.09.02 10:19 
(rgh-soft@t-online.de) | |
Hallo,
in der aktuellen Betaversion ist wie bisher nur eine gleichzeitige SQL-Verbindung über ODBC möglich.
Ein gute Möglichkeit zum Nutzen mehrerer ODBC-Verbindungen ist eben die, die Verbindungen nach jedem Zugriff sofort zu schließen (SQLDone) und die nächste zu öffnen, und so weiter ... In vielen Fällen ist dies sowieso sicherer.
Wie es in Version 8 aussehen wird, vermag ich noch nicht zu sagen.
Gruß
Roland
|
|
| Datum:17.09.02 07:19 
(info@ebs-haase.de) | |
Hi !
Also ich habe immer kackfrech mit SQLINIT neu zugewiesen und dazwischen kein SQLDONE abgesetzt. Das hat bis jetzt auch einwandfrei geklappt. Wäre aber trotzdem wichtig, daß man ohne Probleme 2 bis x Tabellen ansprechen kann (Roland hau rein).
Wie sieht es eigentlich mit SQL-Befehlen aus, die zum Beispiel Tabellenstrukturen auslesen wie z. B. Describe. Diesen konnte ich nicht einsetzen, da es eine Fehlermeldung gab.
Ist dieser Befehl nicht implementiert ?
:) Bernd
|
|
| Datum:17.09.02 08:02 
(rgh-soft@t-online.de) | |
Hallo,
nur damit keine Verwechslungen und Mißverständnisse vorkommen:
Mehrere Tabellen einer Datenbank können natürlich mit einem SQLInit bearbeitet werden, da mit SQLInit ja die Datenbank (Database) und nicht die Tabelle (Table, Entityset) geöffnet wird. Eine Access-Datenbank kann z.B. viele Tabellen enthalten. Bei dBase-Dateien gelten alle Tabellen (dbf-Dateien) in einem Verzeichnis als eine Datenbank.
Was derzeit noch nicht geht, ist die gleichzeitige Bearbeitung von Tabellen aus verschiedenen Datenbanken, z.B. Access und dBase oder lokale Datenbank und Datenbank auf dem Server. Hierzu müßte SQLInit ein Handle zurückliefern und dieses Handle müßte für die Zugriffe verwandt werden (etwa: "sh& = sqlinit(<...>)" und "SQLUse sh&").
Gruß
Roland
|
|
| Datum:18.09.02 07:28 
(info@ebs-haase.de) | |
Stimmt ! Roland hat recht. Tabellen kann man mehrere ansprechen.
Aber wie sieht es denn nun mit den von mir erwähnten Befehl aus ?
|
|
| Datum:25.09.02 09:06 
(rgh-soft@t-online.de) | |
> Wie sieht es eigentlich mit SQL-Befehlen aus, die zum Beispiel
> Tabellenstrukturen auslesen wie z. B. Describe. Diesen konnte
> ich nicht einsetzen, da es eine Fehlermeldung gab.
> Ist dieser Befehl nicht implementiert ?
Welche SQL-Befehle funktionieren und welche nicht, ist allein Sache des verwandten ODBC-Treibers. Alle SQL-Befehle, die dieser erlaubt, lassen sich mit SQLExec absetzen. Hier gibt es deutliche Unterschiede von Datenbanksystem zu Datenbanksystem. Und oftmals kennt die ODBC-Schnittstelle nicht einmal alle SQL-Befehle, die das Datenbanksystem kennt. (PROFAN sorgt lediglich für die Verbindung zum ODBC-Treiber und reicht die Befehle dann einfach weiter.)
Es gibt allerdings in der ODBC-Api (zu finden bei Microsoft, mehrere hundert Seiten mit reichlich Funktionen und ausführlicher Beschreibung) Funktionen, um Informationen über Datenbank und Tabellen in Erfahrung zu bringen. Ich könnte mir durchaus vorstellen, etwas davon - ähnlich wie die Transaktionen - in späteren PROFAN-Versionen einzubauen. In Version 7.6 werde ich aber neben der Systemvariablen &SQLDBC (Handle der geöffneten Datenbank nach SQLINIT) noch die Systemvariable &SQLENV (Environmenrthandle der aktuellen ODBC-Verbindung) einbauen. Damit sind dann die nötigen Infos gegeben, um von PROFAN aus direkt auf die ODBC-API zugreifen zu können.
Gruß
Roland
|
|
| Datum:17.09.02 20:51 
(stelas@web.de) | |
Hallo!
Zwei Sachen fallen mir zu Fehlern in Profan ein:
1. Die WhileLoop-Funktion erlaubt seit Version 7.0e
keine 0 als Parameter. Versionen vor 7.0e erlaubten dies
aber.
2. Es wird doch auch wieder einen Fehlerpatch für Profan 7.5
geben, oder?
CU Steffen.
|
|
| Datum:25.09.02 08:53 
(rgh-soft@t-online.de) | |
> 1. Die WhileLoop-Funktion erlaubt seit Version 7.0e
> keine 0 als Parameter. Versionen vor 7.0e erlaubten dies
> aber.
Mit Version 7e wurde eine Überprüfung eingeführt, ob die Parameter sinnvoll sind: Die Schrittweite darf nicht 0 sein. Ist der Endwert größer als der Startwert, muß die Schrittweise positiv sein, ist er kleiner muß sie negativ sein. Bei WhileLoop 0 wäre nun der Startwert defaultmäßig 1, der Endwert 0 und die Schrittweite defaultmäßig 1. Daraus folgt logicherweise eine Fehlermeldung. Eine solche Schleife macht keinerlei Sinn und kann daher nur ein Programmfehler sein!
> 2. Es wird doch auch wieder einen Fehlerpatch für
> Profan 7.5 geben, oder?
Bisher gibt es noch keinen Anlaß dazu. Die Chancen stehen gut, daß die nächste Version die 7.6 sein wird!
Gruß
Roland
|
|
| Datum: 02.10.02 14:29 
(stelas@web.de) | |
Hallo!
Zu den WhileLoop-Schleifen noch einmal...
Folgendes Beispiel:
Du hast in einem Array n% Elemente (n%=0,1,2,3...).
Nun schreibst Du eine Funktion die alle Elemente
durchgeht und irgendetwas berechnet.
Dies kannst Du ja mit WhileLoop n% ... Wend coden.
Wenn das Array nun aber (zufälligerweise) keine
Elemente (also Null) enthält, kommt ein Syntaxfehler!
Und frühere Profan-Versionen haben dann den While-Block
einfach übergangen...
Das macht z.B. Pascal mit For i:=0 to n Do ... ja auch
so, wenn n=0 ist.
Und diesen "Fehler" hab ich in meinem Programmen immer
ausgenutzt. Jetzt muß man immer noch eine bedingte Abfrage
einbauen... Mehr Schreibaufwand und höhere Verschachtelungs-
tiefe.
Hoffe, ich habe mich jetzt verständlicher ausgedrückt. ;-)
Also, schönen Feiertag und schönes Wochenende.
CU Steffen.
|
|