Datenbank geht weder auf noch zu. [ERLEDIGT]

[Benz]

Hi, ich versuche gerade einen Fehler zu finden.
Und zwar habe ich ein Programm geschrieben das folgendes macht:

Es erstellt eine Datenbank nach diesem Code:

Code: Alles auswählen

PROCEDURE proc_create_dbf(cFileName,aFelder)

   LOCAL i
   LOCAL memlen
   LOCAL memdec
   LOCAL memdbname
   LOCAL memdbname_2
   LOCAL memdbname_3
   LOCAL memdbname_4

      CREATE Struct

      i := 1

      DO WHILE i <= len (aFelder)

         APPEND BLANK
         REPLACE FIELD_NAME WITH aFelder[i,1] , ;
              FIELD_TYPE WITH aFelder[i,2] , ;
              FIELD_LEN  WITH aFelder[i,3]  , ;
              FIELD_DEC  WITH aFelder[i,4]

         i := i + 1
      ENDDO

      CLOSE Struct

      CREATE &cFileName FROM Struct

      ERASE Struct.dbf

      USE &cFileName
      memdbname := func_memdbname(cFileName)
      memdbname_2 := memdbname + "2"
      memdbname_3 := memdbname + "3"
      memdbname_4 := memdbname + "4"

      INDEX ON dtos(datum)+alltrim(zeit) TO &memdbname
      INDEX ON UPPER(labparam) TO &memdbname_2
      INDEX ON dtos(datum)+alltrim(zeit)+UPPER(labparam) TO &memdbname_3
      INDEX ON UPPER(labparam)+dtos(datum)+alltrim(zeit) TO &memdbname_4

      *Select(memdbname)
      &memdbname->(DbCloseArea())

RETURN


FUNCTION func_memdbname(cFileName)
LOCAL memdbname
LOCAL i
LOCAL memanzahl

cFileName := func_pfade_vorne_weg(cFileName)
   i := 1
   DO WHILE i <= len (cFileName)
       if i + 3 <= len(cFileName)
          if (cFileName[i] + cFileName[i+1] + cFileName[i+2] + cFileName[i+3]) == ".dbf"
             memanzahl := i
          endif
       endif
       i := i + 1
   ENDDO
   memdbname := substr(cFileName,1,memanzahl-1)
RETURN memdbname

FUNCTION func_pfade_vorne_weg(cFileName)
LOCAL i
LOCAL memanzahl
i := 1
     DO WHILE i <= len (cFileName)
      if cFilename[i] == "\"
         memanzahl := i
      endif
      i := i +1
     ENDDO

     cFileName := substr(cFileName,memanzahl+1)
RETURN cFileName

Zuvor wurden die folgenden Datenbanken aufgerufen:

Code: Alles auswählen

   USE oberbegr NEW SHARED INDEX oberbeg1.ntx, oberbeg2.ntx
   USE parazuor NEW SHARED INDEX parazuo1.ntx, parazuo2.ntx
   USE reihendb NEW SHARED INDEX reihend1.ntx,reihend2.ntx,reihend3.ntx
   USE labpara NEW SHARED INDEX labpara1,labpara2,labpara3,labpara4
   USE schemata NEW SHARED INDEX schema1,schema2
   USE einstell NEW SHARED INDEX einstell
   USE reihenob NEW SHARED INDEX reiheno1,reiheno2,reiheno3

Wenn ich jetzt das erste mal die Datenbank nach dem obigen Code erstelle funktioniert alles reibungslos.
Dann rufe ich die Procedure ein zweites mal auf, aber noch bevor er überhaupt damit anfängt die neue Datenbank zu erstellen benötigt er die anderen Datenbanken und genau dann kommt dieser Fehler:

(fehler1.png)

Ich habe überprüft, welche Datenbank Schuld ist, und zwar ist das die "reihenob".
Wenn ich msgbox(var2char(Select("reihenob"))) ausgeben lasse bekomme ich 0 zurück.
Demnach müsste die Datenbank ja geschlossen sein oder nicht?
Wenn ich jetzt aber an der Stelle, wo die Fehlermeldung entstanden ist (proc_db_abruf_excel_export(1655)) noch einmal

Code: Alles auswählen

USE reihenob NEW SHARED INDEX reiheno1,reiheno2,reiheno3

mache, dann
kommt "File cannot be opened"(fehler2.png). Also dachte ich mir ja gut ist vielleicht doch noch nicht zu.
Deshalb habe ich vor das

Code: Alles auswählen

USE reihenob NEW SHARED INDEX reiheno1,reiheno2,reiheno3

noch

Code: Alles auswählen

CLOSE reihenob

geschrieben dann komm folgender Fehler:

(fehler3.png)

Kann mir jemand helfen?
Ich verzweifle

[brandelh]

So recht verstanden habe ich dein Problem noch nicht, aber am Anfang hast du sehr umständlichen Code um eine DBF zu erzeugen.
Man braucht keine Strukturdatei, insbesondere wenn man die Felder schon in einem Array hat !

Code: Alles auswählen

PROCEDURE proc_create_dbf(cFileName,aFelder)
   // ich vermute, dass aFelder etwa so aussieht { {"Feld1","C",10,0} , {"Feld2","N",10,2}, ... }
   dbcreate( cFileName, aFelder )
   use (cFileName)  // BESSER (), geht & überhaupt bei local ?
   if neterr()   // NICHT VERGESSEN !
   ... 
   hier kannst du weitere Anpassungen machen
return

[brandelh]

Es ist zwar erlaubt USE ... INDEX in einer Zeile zu schreiben, aber nicht sinnvoll !
Erstens muss man nach USE immer auf NETERR prüfen, zweitens kann man bei getrennten Aufrufen sehen ob eine INDEX oder die DBF nicht geöffnet werden kann.

Auch bei den Indexdateien gilt, dass man & nur zum übersetzen von Code verwenden soll, ich bin mir jetzt zwar nicht sicher ob es tatsächlich bei locals nicht geht (es ist schon so lange her), aber das arbeitet bei mir schon seit Jahren zuverlässig.

Code: Alles auswählen

use (cFilename) // ohne .DBF ! wegen der Indexdatei
if ! neterr() 
   index to (cFilename) 
endif

Auch die Aliasnamen sind nicht mehr so eindeutig wie unter Clipper, denn wenn eine Datei das zweite mal geöffnet wird, entspricht der Alias() nicht mehr dem Dateinamen.
Wenn man weiß, dass eine Datei nur einmal geöffnet wird, kann man einen kurzen Alias vorgeben, ansonsten entweder den numerischen Selectbereich (das nutze ich) oder den Alias in einer Var vorhalten:

Code: Alles auswählen

use (cFilename) // ohne .DBF ! wegen der Indexdatei
if ! neterr() 
   index to (cFilename) 
   nDB := select() 
   cAlias := alias() 

   (nDB)->(dbEval(...))
   (cAlias)->(dbEval(...))

endif

Es gibt einen Vorteil bei numerischen Selectbereichvariablen, angenommen die Dateien sind geschlossen ...

Code: Alles auswählen

   (nDB)->(used()) => .f. // Selectbereich ist frei, also ist die Datei nicht mehr offen.
   (cAlias)->(used()) => Laufzeitfehler unbekannter Alias !

Wofür verwendet man noch & ...

Code: Alles auswählen

cCodeBlock := "{|c| qout(c) }"
bCodeBlock := &(cCodeBlock) // man beachte die Klammer um die local Variable und davor dann &

local cFeldName := "PLZ"
? (cFeldName) => druckt PLZ
? &(cFeldName) => druckt den Inhalt von PLZ

PS: Tippfehler sind möglich, ich schreibe das aus dem Gedächtnis.

[Tom]

Mmh. Keine der gezeigten Fehlermeldungen entstammt dem Code, den Du gepostet hast.

Ansonsten kann ich Huberts Anmerkungen nur unterschreiben. Den Makrooperator kann man in diesen Stellen vermeiden; er frisst auch Performance.

Code: Alles auswählen

USE (cDateiname) NEW // "SHARED" ist überflüssig, wenn SET EXCLUSIVE auf OFF ist, was in Mehrbenutzeranwendungen ohnehin so sein sollte
IF NetErr()
  MsgBox('Tabelle '+cDateiname+' konnte nicht geöffnet werden!')
  RETURN
ENDIF
SET INDEX TO (cIndex1), (cIndex2) usw.

geht natürlich auch hier:

Code: Alles auswählen

INDEX ON DATUM TO (cIndex1)

Die Funktionen etwa zur Ermittlung der Dateinamen ohne Pfad sind etwas haarig. Das geht viel einfacher:

Code: Alles auswählen

FUNCTION Dateiname_ohne_Pfad(cName)
RETURN SubStr(cName,Rat("\",cName)+1)

Warum Du erst eine Tabelle "struct" erzeugst, ist mir auch nicht klar. Du hast doch schon die Struktur in einem Array. Siehe Huberts Anmerkungen.

Aber, wie gesagt - Du postest Code, der nicht betroffen ist.

"Datenbankalias existiert nicht/ist ungültig" (Unknown/Invalid symbol for alias) verweist darauf, dass versucht wird, in einer Workarea zu operieren, die es nicht gibt. Das kann daran liegen, dass die fragliche Tabelle nicht geöffnet werden konnte.

"Datei kann nicht geöffnet werden" (File can not be openend) kann diverse Ursachen haben; hier ist es hilfreich, sich auch den GenCode anzeigen zu lassen (940 beispielsweise bedeutet, dass die DBT fehlt). Die Ursachen können vielfältig sein. Im einfachsten Fall handelt es sich überhaupt nicht um eine gültige DBF. Oder die Tabelle ist einfach nicht vorhanden.
Edit: Der Fehler tritt auch auf, wenn man eine Tabelle gleichzeitig mit ihren Indexen zu öffnen versucht (USE tabelle INDEX index1,index2 usw.), die Tabelle aber nicht geöffnet werden konnte, weil sie exklusiv in Benutzung ist. Der Öffnungsfehler betrifft in diesem Fall also die Indexdateien, denn der Öffnungsfehler bei der Tabelle lässt schlicht NetErr() feuern.

Ach so: Du arbeitest offensichtlich mit der internationalen Version von Xbase++, weshalb Du auch englischsprachige Fehlermeldungen bekommst. Lass Dir mal von Alaska Software die XppNat.DLL für die deutsche Version geben.

[AUGE_OHR]

hi,

Code: Alles auswählen

PROCEDURE proc_create_dbf(cFileName,aFelder)
...
      // KEIN Alltrim() in einem Index  
      INDEX ON dtos(datum)+alltrim(zeit) TO &memdbname
CLOSE INDEX
      INDEX ON UPPER(labparam) TO &memdbname_2
CLOSE INDEX
      // KEIN Alltrim() in einem Index
      INDEX ON dtos(datum)+alltrim(zeit)+UPPER(labparam) TO &memdbname_3
CLOSE INDEX
      // KEIN Alltrim() in einem Index
      INDEX ON UPPER(labparam)+dtos(datum)+alltrim(zeit) TO &memdbname_4
CLOSE INDEX
...
CLOSE MyDBF[/quote]ich würde den Index jedes mal schliessen bevor du einen neuen anfängst.
Ein IndexKey() MUSS immer die selbe Länge haben, deshalb KEIN alltrim() / trim() etc. verwenden.

[brandelh]

Ein IndexKey() MUSS immer die selbe Länge haben, deshalb KEIN alltrim() / trim() etc. verwenden.

genau, das hatte ich übersehen, ist aber extrem wichtig !

Wenn man den Indexbegriff z.b. in einer Funktion "richtet", muss man am Anfang die Länge bestimmen und am Ende diese wieder sicherstellen.

Code: Alles auswählen

function myIndex(cText)
    local nLen := len(cText)
    cText := alltrim(cText)
    ... mach was
    cText := left(cText+space(nLen),nLen)
return cText

wenn man verschiedene Felder mit verschiedenen Typen mischt, kann man das auch in der Funktion verbinden:

Code: Alles auswählen

function myIndexSpezial(cText,dDat,nNumFeld) 
    local nLen := 20
    ... mach was ... Beispiel
    //             8 + 6 (Wertebereich !) + 
    cText := dtos(dDat) + str(nNum,6) + alltrim(cText)
    ...
    cText := left(cText+space(nLen),nLen)
return cText

Für die Indexsuche muss man natürlich die Suchbegriffe dann auch so durch die Funktion erzeugen lassen !

[andreas]

Überprüfe die Zugriffsrechte der Dateien. Ich hatte schon Fälle gehabt, wo die DBF-Dateien vom Programm beim 1. Mal ohne Probleme erzeugt werden konnten. Beim 2. Mal gab es keinen Zugriff mehr darauf. Die Dateien wurden aus irgendeinem Grund mit Admin-Rechten erzeugt, womit ich als normaler User keinen Zugriff mehr darauf bekam.

[AUGE_OHR]

Die Dateien wurden aus irgendeinem Grund mit Admin-Rechten erzeugt, womit ich als normaler User keinen Zugriff mehr darauf bekam.

Frage wo befinden sich die Daten und welches OS() ?
ich tippe mal auf "lokal" und Win7/8 ...

[Benz]

Hi, schonmal danke für all die Antworten!

So recht verstanden habe ich dein Problem noch nicht, aber am Anfang hast du sehr umständlichen Code um eine DBF zu erzeugen.
Man braucht keine Strukturdatei, insbesondere wenn man die Felder schon in einem Array hat !

Ich hatte das als Beispiel von der Xbase - Hilfe kopiert. Kann es sein, dass es daran liegt??

Es ist zwar erlaubt USE ... INDEX in einer Zeile zu schreiben, aber nicht sinnvoll !
Erstens muss man nach USE immer auf NETERR prüfen, zweitens kann man bei getrennten Aufrufen sehen ob eine INDEX oder die DBF nicht geöffnet werden kann.

Das ist ein guter Tipp, wusste ich bisher noch nicht, habe die immer mit USE db NEW SHARD INDEX index, index2,index3, .. aufgemacht. Danke auch dafür!

Code: Alles auswählen

FUNCTION Dateiname_ohne_Pfad(cName)
RETURN SubStr(cName,Rat("\",cName)+1)

Auch dafür, danke!

"Datei kann nicht geöffnet werden" (File can not be openend) kann diverse Ursachen haben; hier ist es hilfreich, sich auch den GenCode anzeigen zu lassen (940 beispielsweise bedeutet, dass die DBT fehlt). Die Ursachen können vielfältig sein. Im einfachsten Fall handelt es sich überhaupt nicht um eine gültige DBF. Oder die Tabelle ist einfach nicht vorhanden.
Edit: Der Fehler tritt auch auf, wenn man eine Tabelle gleichzeitig mit ihren Indexen zu öffnen versucht (USE tabelle INDEX index1,index2 usw.), die Tabelle aber nicht geöffnet werden konnte, weil sie exklusiv in Benutzung ist. Der Öffnungsfehler betrifft in diesem Fall also die Indexdateien, denn der Öffnungsfehler bei der Tabelle lässt schlicht NetErr() feuern.

Wie lasse ich mir den GenCode ausgeben und wo kann ich die Bedeutungen der Fehlercodes nachschlagen?
Also die dbf ist gültig und auch vorhanden, sonst würde sie im ersten Durchgang ja auch nicht funktionieren, aber das zweite, was du sagtest, dass sie möglicherweise noch exclusive geöffnet ist, halte ich in meinem Fall für möglich, das werde ich als erstes mal versuchen.

ich würde den Index jedes mal schliessen bevor du einen neuen anfängst.
Ein IndexKey() MUSS immer die selbe Länge haben, deshalb KEIN alltrim() / trim() etc. verwenden.

Auch danke für diese beiden Tipps! Mit alltrim hatte ich schon des öfteren Probleme, das sollte ich auf jeden Fall wieder korrigieren, ist mir gar nicht mehr aufgefallen, dass da noch alltrim dranstand.

Überprüfe die Zugriffsrechte der Dateien. Ich hatte schon Fälle gehabt, wo die DBF-Dateien vom Programm beim 1. Mal ohne Probleme erzeugt werden konnten. Beim 2. Mal gab es keinen Zugriff mehr darauf. Die Dateien wurden aus irgendeinem Grund mit Admin-Rechten erzeugt, womit ich als normaler User keinen Zugriff mehr darauf bekam.

Auch dafür danke, werde daran auch einmal herumprobieren, ob das der Fehler ist.

Frage wo befinden sich die Daten und welches OS() ?
ich tippe mal auf "lokal" und Win7/8 ...

Sie befinden sich lokal, im gleichen Ordner wie die exe - Datei, mit Ausnahme der umständlich über die "Struct" - DB erzeugten Datenbank.

[brandelh]

Wenn die DBF im EXE Verzeichnis liegen soll, darf es keinesfalls unter c:\Programme\... liegen.
Ab Vista, spätestens ab Win7 verhält sich eine EXE ohne Adminrechte dann sehr seltsam.

[Benz]

okay, guter Tipp, werds beachten!

Ich habe das Problem jetzt gelöst. Habe 25 MsgBox's reingemacht und mir Select("reihenob") überall anzeigen lassen, um zu schauen, wann diese 0 wird.
Der !böse! Befehl war das CREATE bei der Erzeugung von Struct. Wenn davor nämlich nicht SELECT(0) steht (greift auf den nächsten freien DBplatz zu), dann überschreibt CREATE den momentan geöffneten DBplatz. Deshalb wird SELECT("reihenob") direkt nach CREATE := 0.

Hier mein Lösungscode, habe eure Tipps berücksichtigt und den Code umgestellt:

Code: Alles auswählen

PROCEDURE proc_create_dbf(cFileName,aFelder)

   LOCAL i
   LOCAL memlen
   LOCAL memdec
   LOCAL memdbname
   LOCAL memdbname_2
   LOCAL memdbname_3
   LOCAL memdbname_4

     memdbname := func_memdbname(cFileName)

     if select(memdbname) <> 0
         CLOSE &memdbname
     endif

     SELECT(0)
     dbcreate( cFileName, aFelder )

     use (cFileName)  // BESSER (), geht & überhaupt bei local ?
     if neterr()   // NICHT VERGESSEN !
       MsgBox('Tabelle '+cFileName+' konnte nicht geöffnet werden!')
       RETURN
     endif
/*

      i := 1

      DO WHILE i <= len (aFelder)

         APPEND BLANK
         REPLACE FIELD_NAME WITH aFelder[i,1] , ;
              FIELD_TYPE WITH aFelder[i,2] , ;
              FIELD_LEN  WITH aFelder[i,3]  , ;
              FIELD_DEC  WITH aFelder[i,4]

         i := i + 1
      ENDDO

      msgbox("use")
      CLOSE &cFileName

      USE &cFileName
      */

      memdbname := func_memdbname(cFileName)
      memdbname_2 := memdbname + "2"
      memdbname_3 := memdbname + "3"
      memdbname_4 := memdbname + "4"

      INDEX ON dtos(datum)+alltrim(zeit) TO (memdbname)
      CLOSE INDEX
      INDEX ON UPPER(labparam) TO (memdbname_2)
      CLOSE INDEX
      INDEX ON dtos(datum)+alltrim(zeit)+UPPER(labparam) TO (memdbname_3)
      CLOSE INDEX
      INDEX ON UPPER(labparam)+dtos(datum)+alltrim(zeit) TO (memdbname_4)
      CLOSE INDEX

      *Select(memdbname)
      *&memdbname->(DbCloseArea())
      CLOSE (memdbname)

RETURN

Danke an euch alle!! Ich mag dieses Forum Hier wird einem geholfen

[Koverhage]

Wie lasse ich mir den GenCode ausgeben und wo kann ich die Bedeutungen der Fehlercodes nachschlagen?

Der GenCode wird in die XPPERROR.log geschrieben.

[Benz]

Danke