Seite 1 von 1
DBU und i, j, k
Verfasst: Di, 10. Okt 2017 10:03
von AUGE_OHR
hi,
ich war mal am Original DBU Source um es nach Xbase++ VIO zu portieren. Das ganze war in paar Minuten erledigt.
dann habe ich mit der Option
/w compiliert und dem entsprechend hat er eine lange Liste an Warnungen ausgespuckt.
mir war schon klar das es viele PRIVATE / DECLARE gibt die irgendwo im DBU Source auftauchen können.
dann sah ich eine solche Konstruktion
na klar habe ich mir gedacht das ist bestimmt für irgendwelche Schleifen gedacht also suchte ich nach "FOR i".
zu meinem Erstaunen fand ich nichts in dem PRG ...
dann mal "M->i" und d gab es viele Treffer und das in mehreren PRG Dateien
eine PRIVAT die aus 1 x Zeichen besteht ... wie soll man so was in einem Project finden
ok die sind zwar alle mit "M->i" geschrieben aber verwirrend ist es schon i,j,k durch ganz DBU zu jagen ...
hat man früher wirklich so programmiert
Re: DBU und i, j, k
Verfasst: Di, 10. Okt 2017 10:11
von Martin Altmann
Die findet man doch leicht in einem geeigneten Editor:
Suche nach: i
[x] Ganzes Wort
Mehr Optionen braucht es nicht.
Viele Grüße,
Martin
Re: DBU und i, j, k
Verfasst: Di, 10. Okt 2017 10:12
von Jan
AUGE_OHR hat geschrieben: ↑Di, 10. Okt 2017 10:03hat man früher wirklich so programmiert
Ja klar! Und um ehrlich zu sein - in FOR...NEXT-Schleifen mache ich das heute noch so. Meistens. Ab und an habe ich auch Erbarmen mit mir und benutze ordentlich benamte Zähl-Variablen. Aber meistens schlägt die alte Angewohnheit doch wieder durch , und dann kommt doch wieder i.
Bei einem Kunden von mir gibt es zusätzlich stapelweise normale Variablen (also nicht in Zählschleifen) wie x, zz, h, usw. Sogar Feldnamen, die nur aus einem Buchstaben bestehen, und natürlich nicht mit dem Alias davorgestellt genutzt werden. Das ist ist immer eine Sucherei ...
Jan
Re: DBU und i, j, k
Verfasst: Di, 10. Okt 2017 11:15
von DelUser01
AUGE_OHR hat geschrieben: ↑Di, 10. Okt 2017 10:03hat man früher wirklich so programmiert
was hat das mit "früher" zu tun?
Re: DBU und i, j, k
Verfasst: Di, 10. Okt 2017 11:17
von Jan
Roland,
insofern, als das wir ja alle lernfähig sind, Erfahrungen machen, und damit heute lieber "sprechende" Variablennamen benutzen, die sich auch leicht finden lassen. Und auch nicht mehr ultrakurze Variablennamen benutzen, nur weil die Programmiersprache oder der Speicherplatz auf der Diskette nicht mehr hergeben.
Jan
Re: DBU und i, j, k
Verfasst: Di, 10. Okt 2017 11:26
von DelUser01
Servus Jan
das ist doch klar dass das besser ist mit sprechenen Variablen.
Da es aber nicht nur bei Alaska in den Sources und Dokus noch viele Beispiele mit Variablen in der Form i, j, k geben wird kann man davon ausgehen, dass Neulinge auch wieder mit diesen Kurznamen anfangen werden.
(Nicht nur in Xbase++, in vielen Codes im Internet, MSDN usw.)
Und es funktioniert ja auch - deshalb zeitlos...
Re: DBU und i, j, k
Verfasst: Di, 10. Okt 2017 14:06
von Herbert
Jimmy, DBU ist ein Konstrukt, welches seit Uraltzeiten besteht und jeweils nur angepasst wurde. Daher die Uralt-Dinge, welche heute als fatale Falschprogrammierung enttarnt werden.
Re: DBU und i, j, k
Verfasst: Di, 10. Okt 2017 15:47
von Koverhage
Herbert,
so ein Schmarn. DBU läuft im Gegensatz zu vielen anderen Programmen bis heute klaglos.
Möchte nicht Deine Programme aus der Zeit sehen.
Re: DBU und i, j, k
Verfasst: Di, 10. Okt 2017 15:57
von Jan
Hallo Klaus,
naja, so ganz Unrecht hat Herbert ja nicht. Sehr viel, was in dbu programmiert ist bzw. wie, würde heute vermutlich kaum einer von uns heute noch so machen. Der Stil der Programmierung hat sich halt geändert im Laufe der Jahre und Jahrzehnte.
Was aber, und da stimme ich mit Dir überein, nichts daran ändert, das dbu trotz des aus heutiger Sicht streckenweise kruden Codes immer noch ein Muster an Stabilität ist.
Jan
Re: DBU und i, j, k
Verfasst: Di, 10. Okt 2017 17:01
von Bertram Hansen
Einspruch!
Wenn man mit dem alten DBU eine Strukturänderung einer Tabelle macht (Feldnamen und gleichzeitig Feldlänge ändert) dann gibt es eine Absturz.
Sonst sind mir persönlich keine weiteren "Fehler" bekannt.
Re: DBU und i, j, k
Verfasst: Di, 10. Okt 2017 19:40
von AUGE_OHR
hi,
ich habe von PRIVATE i,j,k gesprochen nicht von LOCAL wie ich es auch in der Kurzform verwende.
JA ich glaube DBU kommt noch von Summer87 und da gab es noch keine LOCAL
Re: DBU und i, j, k
Verfasst: Mi, 11. Okt 2017 7:23
von AUGE_OHR
Bertram Hansen hat geschrieben: ↑Di, 10. Okt 2017 17:01
Wenn man mit dem alten DBU eine Strukturänderung einer Tabelle macht (Feldnamen und gleichzeitig Feldlänge ändert) dann gibt es eine Absturz.
es liegt nicht am Code von DBU denn die Cl*pper Version machte es ohne Probleme.
Code: Alles auswählen
DBUSTRU.PRG ca. Zeile 1270
stat_msg(IF(new_name <> "J", "Ändere Dateistruktur",;
"Ändrere Feldname(n)"))
* save the old and create the new
RENAME &filename TO &name_temp
cAlias := MakeAlias( filename )
CREATE &filename FROM ddbbuuuu.ext ALIAS cAlias
IF new_name = "J"
* change field names by copying SDF
USE &name_temp
COPY TO ddbbuuuu.txt SDF
USE &filename
APPEND FROM ddbbuuuu.txt SDF
ERASE ddbbuuuu.txt
ELSE
* normal modify structure
APPEND FROM &name_temp
ENDIF
Das Xbase++ Problem liegt in SDFDBE wo ich beim Export/Import nie wirklich klar gekommen bin mit dem "Ergebnis".
wenn man die COPY TO / APPEND FROM auf FWrite() / FRead() umschreibt und mit FieldPut() arbeitet funktioniert es einwandfrei.
Re: DBU und i, j, k
Verfasst: Do, 12. Okt 2017 8:05
von Herbert
Koverhage hat geschrieben: ↑Di, 10. Okt 2017 15:47
Herbert,
so ein Schmarn. DBU läuft im Gegensatz zu vielen anderen Programmen bis heute klaglos.
Möchte nicht Deine Programme aus der Zeit sehen.
Eh, habe ich doch gar nicht behauptet...
Jan hat geschrieben: ↑Di, 10. Okt 2017 15:57
naja, so ganz Unrecht hat Herbert ja nicht. Sehr viel, was in dbu programmiert ist bzw. wie, würde heute vermutlich kaum einer von uns heute noch so machen. Der Stil der Programmierung hat sich halt geändert im Laufe der Jahre und Jahrzehnte.
Jan, danke, genau so meinte ich die Sache!
Re: DBU und i, j, k
Verfasst: Sa, 14. Okt 2017 3:59
von AUGE_OHR
ich "denke" ich habe raus wofür M->
i steht : es ist der SELECT() Ausdruck
PRIVATE und DECLARE sind zusammen > 300 ...
alles in eine *.CH Datei "generiert" damit ich nicht die ganzen /Warnungen sehe ... und dabei den Fehler übersehe
Frage : wenn ich aus einer PRIVATE eine LOCAL mache und vergesse die MEMVAR aus der *.CH zu löschen ... wie "finde" ich die
---
DBU ist ja nur für NTX ausgelegt. es werden nur *.NTX Index Dateien angezeigt obwohl der Title "*.CDX" ( IndexExt() ) anzeigt. ich kam nun darauf das es eine Prüfung geben müsste und fand NTX_KEY() welche z.b. einen "leeren" CDX IndexKey() anzeigte. der Grund ist nun diese Stelle im Original DBU Source
Code: Alles auswählen
═ DBUUTIL.PRG ═ ca. Zeile 2845
FUNCTION ntx_key()
...
* open the file and get handle
handle = FOPEN( M->filename )
IF FERROR() = 0
* allocate 512 byte buffer
buffer = SPACE( 512 )
* read the index file header into memory
FREAD( M->handle, @buffer, 512 )
* discard all bytes before the key expression
k = SUBSTR( M->buffer, M->k_pos )
* the expression is terminated with a zero byte (chr(0))
k = TRIM( SUBSTR( M->k, 1, AT( CHR( 0 ), M->k ) - 1 ) )
ENDIF
* close the file and release the handle
FCLOSE( M->handle )
das ganze diente (früher) dazu den INDEXKEY(), von NTX Dateien, auszulesen aber funktioniert natürlich nicht mit CDX