Re: Datensatzbereich ist schreibgeschützt
Lysander
> Beim Testen meiner Updates meldet dBase den Fehler "Datensatzbereich ist
> schreibgeschützt" oder "Fehler der Datenbank-Engine: Tabelle ist
> schreibgeschützt". Er tritt erst auf, seit ich die Version 2.6.1.4 verwende.
Hast du, bewusst oder unbewusst, die Eigenschaft "RequestLive" der
Query-Objekte auf "false" gestellt, anstatt auf "true". Danach hört es
sich an, so wie du es beschreibst.
Du solltest mal einen kompletten Code-Abschnitt posten, dann können wir
dir u.U. besser helfen.
Evtl. kann auch jemand noch aushelfen, der bessere Kenntnis über die
2.6.1.4. hat. War da im Zuge der Umstellung auf bessere Zusammenarbeit
mit SQL-Servern evtl. der Standard von RequestLive=true umgestellt worden?
Silvio Veronesi
schreibgeschützt" oder "Fehler der Datenbank-Engine: Tabelle ist
schreibgeschützt". Er tritt erst auf, seit ich die Version 2.6.1.4 verwende.
diese Probleme nicht.
Der Fehler tritt unabhängig davon auf, ob die Anwendung auf dem Server offen
ist oder nicht, sowie ich auf dem Client eine Query _verändern_ will.
Etwa mit:
form.Q_EINST_ID.rowset.fields['LIB'].value := 'Zugang zu LibroData ohne
Passwort'
Die Eigenschaft active ist true sowohl für das Datenbankobjekt wie auch für
die Query.
Ich befürchte, dass ich wesentliche Vorschriften im Umgang mit Netzwerken
nicht kenne oder nicht begriffen habe.
Silvio
Lysander
>> Du solltest mal einen kompletten Code-Abschnitt posten, dann können wir
>> dir u.U. besser helfen.
> Ich glaube nicht, dass das weiterhilft;
Das ist keine Glaubensfrage.
Mir würden auf Anhieb noch ein Dutzend möglicher Knackpunkte einfallen,
die man alle entweder ausschliessen oder weiter verfolgen könnte, wenn
man mal die Objekte und die Funktion zum Speichern sehen könnte.
Aber man ja keinen zwingen, sich helfen zu lassen.
Wenn es alle Queries betrifft, dann kannst du doch sicherlich ein
kleines DEMO.wfm erstellen, was mit deiner Anwendung gar nix zu tun hat,
welches aber auch den Fehler aufweist. Wenn du das nicht kannst, hast du
das Problem schon gelöst, wenn doch, dann kann es bestimmt mithilfe der
Newsgroup gelöst werden.
> Auf dem Client werden einfach keine Einträge in die Queries geduldet.
Aber auf dem anderen, dem "übergeordneten" Rechner geht alles einwandfrei?
*Lysander*
> function PUSHBUTTON1_onClick
> form.rowset.beginAppend()
> form.rowset.fields['ALTER'].value := 'Zittergreise'
> form.rowset.save()
> return
Da war was.... ist uns im Rahmen eines Firebird-Workshops aufgefallen,
betraf allerdings NUR Forms bei der Verwendung von form.rowset...
(anstatt form.queryXY.rowset...)
Und das betraf auch nur diejenigen mit Version 2.5.x und höher.
In deinem ersten Beispiel hast du aber genau die zweite Syntax verwendet.
Probiere es bitte nochmal mit
form.alter1.rowset.beginAppend()
form.alter1.rowset.fields[1].value := 'Zittergreise'
form.alter1.rowset.save()
Und prüfe bitte unbedingt mal den Status von RequestLive
msgbox(form.rowset.parent.requestlive)
Silvio Veronesi
news:OOvrhx3QJHA.1568@news-server...
> *Lysander* schrieb:
> Und das betraf auch nur diejenigen mit Version 2.5.x und höher.
Liegt's vielleicht tatsächlich an der neuen Version? Mit 2.01 hat's ja
geklappt!
> Bei Rauswurf der KMCustButtons und des "Form.Rowset = ...." ging wieder
> alles.
>
> Probier's mal... vielleicht war's das auch bei dir.
Leider nein. Es bleibt beim alten.
> Und prüfe bitte unbedingt mal den Status von RequestLive
RequestLive ist true.
Könnte es sein, dass beim Zuordnen der Eigenschaften der Queries irgend
etwas Anderes noch eine Rolle spielen könnte? Oder könnte die BDE klemmen?
*Lysander*
> Da war was.... ist uns im Rahmen eines Firebird-Workshops aufgefallen,
> betraf allerdings NUR Forms bei der Verwendung von form.rowset...
> (anstatt form.queryXY.rowset...)
>
> Und das betraf auch nur diejenigen mit Version 2.5.x und höher.
Winfried.... Winfried war davon betroffen, aber ob der sich noch erinnert...
Das Problem war, dass man eigentlich diese vorgefertigten KMCustButtons
nicht wirklich benutzen sollte... (okay, okay... Ansichtssache...)
Jedenfalls setzen diese Leisten ja zwingend ein "form.RowSet" voraus,
und irgendwie traten bei Verwendung dieser KMCustButtons dann immer
Schreibschutzsperrenfehlermeldungen auf, und zwar AUCH dann wenn man zum
Speichern über das Query-Objekt ging.
Alfred Unkrig
> in 2.6.1.4 vollständig ausprobieren.
Silvio, 3 Zimmer haben wir noch; also auf nach Marienheide!
Silvio Veronesi
"Lysander" <nob...@nowhere.de> schrieb im Newsbeitrag
news:KPPNd5xQJHA.1584@news-server...
> Hast du, bewusst oder unbewusst, die Eigenschaft "RequestLive" der
> Query-Objekte auf "false" gestellt, anstatt auf "true". Danach hört es
> sich an, so wie du es beschreibst.
> Du solltest mal einen kompletten Code-Abschnitt posten, dann können wir
> dir u.U. besser helfen.
Ich glaube nicht, dass das weiterhilft; die Fehlermeldung betrifft alle
Queries. Ein kleines Beispiel habe ich bereits gepostet. Aber im Prinzip
gleichen alle einander.
Auf dem Client werden einfach keine Einträge in die Queries geduldet. Da ich
auf dem Client dBase bewusst nicht installiert habe, kann ich die fraglichen
Stellen auch nicht debuggen oder mit dem Inspector untersuchen.
Ich habe bestimmt etwas falsch gemacht, aber ich weiss nicht, wo ich noch
suchen könnte.
Silvio Veronesi
>> Auf dem Client werden einfach keine Einträge in die Queries geduldet.
> Aber auf dem anderen, dem "übergeordneten" Rechner geht alles einwandfrei?
Alles bestens!
Beim nachstehenden Code geschieht das selbe. Auf dem "Grossen" läufts, auf
dem "Kleinen" knallts.
Ich musste etwas pröbeln, damit die Umgebung einigermassen so ist wie auf
meinem Rechner.
Da aber in der Zeile mit "create table" anscheinend noch ein Fehler steckt
habe ich den Code im Header zwischen Kommentarzeichen gesetzt.
/*
local cDirectory
cDirectory = 'C:\Programme\LibroData' // ggf. ändern
set procedure to bdeAlias.cc additive
b = new BDEALIAS()
if not b.databaseFound("LibroData")
b.createAlias('LibroData',cDirectory+'\Datenbank')
endif
if file (cDirectory+'\Datenbank\ALTER.DBF')
erase cDirectory+'\Datenbank\ALTER.DBF'
endif
create table cDirectory+'\Datenbank\ALTER.DBF';
(LESEALTER char(20))
use cDirectory+'\Datenbank\ALTER.DBF' excl
generate 6
go top
repla LESEALTER with '<alle>'
skip
repla LESEALTER with '<leer>'
skip
repla LESEALTER with 'Kinder'
skip
repla LESEALTER with 'Jugend I'
skip
repla LESEALTER with 'Jugend II'
skip
repla LESEALTER with 'Erwachsene'
use
*/
** END HEADER -- Diese Zeile nicht entfernen
//
// Erstellt am 10.11.2008
//
parameter bModal
local f
f = new LesealterForm()
if (bModal)
f.mdi = false // Nicht-MDI festlegen
f.ReadModal()
else
f.Open()
endif
class LesealterForm of FORM
with (this)
open = class::BEFOREOPEN
readModal = class::BEFOREOPEN
height = 6.7727
left = 100.0
top = 0.0
width = 41.5714
autoCenter = true
mdi = false
text = "Lesealter"
escExit = false
endwith
this.DTB_V = new DATABASE()
this.DTB_V.parent = this
with (this.DTB_V)
left = -0.1429
top = -0.7273
databaseName = "LibroData"
active = true
endwith
this.ALTER1 = new QUERY()
this.ALTER1.parent = this
with (this.ALTER1)
left = 5.0
top = -0.6364
database = form.dtb_v
sql = 'select * from "alter.dbf"'
active = true
endwith
this.PUSHBUTTON1 = new PUSHBUTTON(this)
with (this.PUSHBUTTON1)
onClick = class::PUSHBUTTON1_ONCLICK
height = 1.0909
left = 1.0
top = 1.5
width = 15.2857
text = "Neue Zeile"
endwith
this.PUSHBUTTON2 = new PUSHBUTTON(this)
with (this.PUSHBUTTON2)
onClick = class::PUSHBUTTON2_ONCLICK
height = 1.0909
left = 1.0
top = 3.5
width = 15.2857
text = "Zeile löschen"
endwith
this.LISTBOX1 = new LISTBOX(this)
with (this.LISTBOX1)
height = 6.0
left = 22.0
top = 0.0
width = 17.0
id = 104
dataSource = form.alter1.rowset.fields["alter"]
endwith
this.rowset = this.alter1.rowset
function beforeOpen
return super::open()
function PUSHBUTTON1_onClick
form.rowset.beginAppend()
form.rowset.fields['ALTER'].value := 'Zittergreise'
form.rowset.save()
return
function PUSHBUTTON2_onClick
form.rowset.delete()
form.rowset.save()
return
endclass
*Lysander*
> Könnte es sein, dass beim Zuordnen der Eigenschaften der Queries irgend
> etwas Anderes noch eine Rolle spielen könnte? Oder könnte die BDE klemmen?
Also, wenn du die "form.Rowset" aus deinem Programm geworfen hast, fällt
mir derzeit nix ein, warum es mit 2.1.6.4 nicht gehen sollte, und mit
einer niedrigeren Version doch (gleicher Rechner, gleiches System... usw..)
Windows-Rechte können keine Rolle spielen, wenn sich nur die
dBase-Version geändert hat.
BDE (eigentlich) auch nicht.
Vielleicht fällt noch jemandem was ein.
H.Tilbert
hast Du mal auf Betriebssystemseite geprüft ob die Tabellen vielleicht
schreibgeschützt sind? Habe mal mit dem Explorer Dateien von der CD kopiert,
dann sind die Daten auf der Festplatte schreibgeschützt weil die Basis auf
der CD auch schreibgeschützt sind. Wenn Du dann eine Änderung in die Tabelle
schreiben willst erhälst Du auch die Fehlermeldung wie beschrieben.
Gruß Hardy
---------
"Silvio Veronesi" <silvio....@bluewin.ch> schrieb im Newsbeitrag
news:5DLTy1xQJHA.1588@news-server...
Lysander
> Hallo Silvio,
> hast Du mal auf Betriebssystemseite geprüft ob die Tabellen vielleicht
> schreibgeschützt sind? Habe mal mit dem Explorer Dateien von der CD kopiert,
> dann sind die Daten auf der Festplatte schreibgeschützt weil die Basis auf
> der CD auch schreibgeschützt sind. Wenn Du dann eine Änderung in die Tabelle
> schreiben willst erhälst Du auch die Fehlermeldung wie beschrieben.
Guter Hinweis! Denn das passiert auch oft genug.
Toll ist auch, eine .exe mit dem Internet-Explorer per FTP zu holen, die
geht dann grundsätzlich nicht, es sei denn man fügt die FTP-Quelle zur
vertrauenswürdigen Zone hinzu.
Dann dürfte es aber nicht von einem Rechner aus gehen, vom anderen nicht.
Auch dürfte es dann nicht mal gehen, wenn man 2.0.1 benutzt und nicht
gehen, wenn man 2.6.1.4 benutzt. Silvio hat das ja alles schon
durchgetestet.
S.Kirschner
<silvio....@bluewin.ch>:
Schau mal in BDE- Verwaltung nach ob du bei Konfiguration> Konfiguration >
Treiber > Native > DBASE dort bei LEVEL die Version 7 hast. Ich vermute
mal das es auf Level 5 steht. Dann bitte auf Level 7 stellen.
mfg S.Kirschner
Silvio Veronesi
"Rainald" <tae...@web.de> schrieb im Newsbeitrag
news:z2ZjWU7QJHA.1744@news-server...
> Alfred Unkrig schrieb:
>
>>> Ansonsten kann ich - aber wohl erst nach der Konferenz - mal
>>> deinen Code in 2.6.1.4 vollständig ausprobieren.
>>
>> Silvio, 3 Zimmer haben wir noch; also auf nach Marienheide!
>
> Jaaaaaa!
> Jaaaaaa!
> Laßt den Silvio anresien.
> Ich würde mich narrisch freuen!
>
> Und das Problem kriegen wir dort garntiert geregelt <g>
Schön, ich komme. Ich kann mit René Debrunner mitfahren und werde bereits am
Donnerstag eintreffen und bleibe bis Sonntagmorgen. Einzelzimmer. Mobile:
+41 79 457 10 60. Weststrasse 2, CH 8820 Wädenswil
Leider kann ich mich nicht mit dem offiziellen Adobe-Formular anmelden. Mein
Reader spinnt seit einiger Zeit.
Genügt diese Anmeldung?
Bis dann also
Silvio
Rainald
>> Ansonsten kann ich - aber wohl erst nach der Konferenz - mal
>> deinen Code in 2.6.1.4 vollständig ausprobieren.
>
> Silvio, 3 Zimmer haben wir noch; also auf nach Marienheide!
Jaaaaaa!
Jaaaaaa!
Laßt den Silvio anresien.
Ich würde mich narrisch freuen!
Und das Problem kriegen wir dort garntiert geregelt <g>
Rainald
Lysander
Sicher!
Freut mich, dich mal persönlich kennenzulernen. Wir hatten ja schon mal
eine kurze Skype-Konferenz, die dann mangels Bandbreite doch nicht
wirklich effizient war :)
Sollen wohl Leute mit verschiedenen dBase-Versionen da sein, und dann
bringst du am besten dein Programm mal mit. Wenn wir den Fehler da nicht
reproduzieren können, dann bleibt nur die Suche bei deinem Netzwerkaufbau.
Peter Schneider
ich bin begeistert. Sobald ich etwas Zeit finde, schicke ich Dir die
Anmeldungsbestätigung zu.
Bis Donnerstag,
--
Gruß aus der Hellwegstadt Wattenscheid
Peter
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dB-D-A-CH Jahreskonferenz 2008
14. und 15. November 2008 in Marienheide
www.dbdach.org
"Silvio Veronesi" <silvio....@bluewin.ch> schrieb im Newsbeitrag
news:spk1do%23QJHA.1744@news-server...
Lysander
> Abgesehen davon:
> Es würde mich sehr erstaunen, wenn die schreibgeschützten CD-Dateien beim
> Kopieren ihren Schreibschutz behielten.
Das tun die aber tatsächlich oftmals. Hängt von der Windows-Version ab.
Rainald
>>> Silvio, 3 Zimmer haben wir noch; also auf nach Marienheide!
>>
>> Jaaaaaa!
>> Jaaaaaa!
>> Laßt den Silvio anresien.
>> Ich würde mich narrisch freuen!
>>
>> Und das Problem kriegen wir dort garntiert geregelt <g>
>
> Schön, ich komme. Ich kann mit René Debrunner mitfahren und werde
> bereits am Donnerstag eintreffen und bleibe bis Sonntagmorgen.
> Einzelzimmer.
Spitze!!
Rainald
Silvio Veronesi
"H.Tilbert" <nor...@please.com> schrieb im Newsbeitrag
news:o$MU8C9QJHA.1608@news-server...
> Hallo Silvio,
> hast Du mal auf Betriebssystemseite geprüft ob die Tabellen vielleicht
> schreibgeschützt sind? Habe mal mit dem Explorer Dateien von der CD
> kopiert,
> dann sind die Daten auf der Festplatte schreibgeschützt weil die Basis auf
> der CD auch schreibgeschützt sind. Wenn Du dann eine Änderung in die
> Tabelle
> schreiben willst erhälst Du auch die Fehlermeldung wie beschrieben.
Hallo H.Tilbert (?)
Danke für den Hinweis.
Server und Client greifen auf die selben Server-Datenbanken zu. Wären sie
schreibgeschützt, hätte ich ja auf dem Server das gleiche Problem. Für die
Clienteinrichtung werden keine Tabellen von der CD kopiert. Abgesehen davon:
Es würde mich sehr erstaunen, wenn die schreibgeschützten CD-Dateien beim
Kopieren ihren Schreibschutz behielten.
Gruss
Silvio
Silvio Veronesi
"S.Kirschner" <S.Kir...@oberhollenzer.de> schrieb im Newsbeitrag
news:op.ukgj1ic398w24j@alfred2...
> Schau mal in BDE- Verwaltung nach ob du bei Konfiguration> Konfiguration >
> Treiber > Native > DBASE dort bei LEVEL die Version 7 hast. Ich vermute
> mal das es auf Level 5 steht. Dann bitte auf Level 7 stellen.
Version ist 4.0, Level ist 7.
Danke für den Hinweis
Silvio
Rainald
> Schön, ich komme.
Ist eigentlich Dein Problem aus dem Thread "Datensatzbereich ist
schreibgeschützt" jetzt gelöst?
Rainald
Silvio Veronesi
> Ist eigentlich Dein Problem aus dem Thread "Datensatzbereich ist
> schreibgeschützt" jetzt gelöst?
Es sieht ganz danach aus ;-)
Gruss
Silvio
Rainald
>> Ist eigentlich Dein Problem aus dem Thread "Datensatzbereich ist
>> schreibgeschützt" jetzt gelöst?
>
> Es sieht ganz danach aus ;-)
Na, das wäre ja Spitze!
Hast Du es in der früheren Kombination getestet?
Derjenige, der Dir die zweite Partition mit FAT32 eingerichtet hatte,
sollte sich wohl sein Lehrgeld zurückgeben lassen ...
Rainald
*Lysander*
> Derjenige, der Dir die zweite Partition mit FAT32 eingerichtet hatte,
> sollte sich wohl sein Lehrgeld zurückgeben lassen ...
Zwar würde ich kein FAT32 mehr einrichten, aber so ganz pauschal kann
man es nicht verurteilen. Es gibt Systeme, die können NTFS zwar richtig
lesen, aber nicht richtig schreiben.
Mal angenommen, diese "zweite" Partition war von vornherein als
Datenpartition auch für andere Systeme gedacht (Dual-Boot Win/Linux)
oder z.B. als File-Server für irgendeinen Media-Streamer, dann könnte
das tatsächlich Sinn machen.