Seite 1 von 1

kein update auf Datenbank

Verfasst: Sa, 09. Jan 2016 12:10
von rsz
Hallo zusammen,

ich bin am verzweifeln. Jetzt läuft schon sehr viel nach den Umstellung und ich habe nicht gemerkt seit wann der update der dbf nicht mehr geht.

ich lasse mir einen Datensatzt anzeigen, mache einen get/read darauf (direkt auf DB-Feld) und beim nächsten anzeigne ist wieder der alte wert drin :(
(ging aber schon mal!) wenn ich den get auf Variablen mache und dann replace funktioniert es!

ich steh total auf'm Schlauch, hat jemand einen Tip für mich?

Danke, LG,
Ralf

Re: kein update auf Datenbank

Verfasst: Sa, 09. Jan 2016 12:44
von rsz
also, herausgefunden habe ich:

funktioniert nicht: @ 17,12 get coftatext

funktioniert: @ 17,12 get unisystem->coftatext mit dem datenbanknamen-> vornedran.

jetzt wäre es aber ne menge Arbeit alle get's zu ändern! gibt es dazu eine SET-Anweisung oder einen anderen trick?

:) LG,
Ralf

Re: kein update auf Datenbank

Verfasst: Sa, 09. Jan 2016 12:45
von Rudolf
Hallo,
Source Code würde helfen
Grüße
Rudolf

Re: kein update auf Datenbank

Verfasst: Sa, 09. Jan 2016 12:56
von rsz
Hallo Rudolf,

gerne, hier ist er..

Code: Alles auswählen

//  geöffnete DB selectieren
	select unisystem

	if netget()
		_clwrkbs()

		farbe(_cowin)

		_winx(03,10,19,80,msgtext(166))

		farbe(_cowinget)
		
		@ 05,12 say msgtext(167)+ " (cobs      ) " GUICOLOR _cobs       get cobs       
		@ 06,12 say msgtext(168)+ " (cosayget  ) " GUICOLOR _cosayget   get cosayget   
		@ 07,12 say msgtext(169)+ " (cosayinget) " GUICOLOR _cosayinget get cosayinget 
		@ 08,12 say msgtext(170)+ " (coueb     ) " GUICOLOR _coueb      get coueb      
		@ 09,12 say msgtext(171)+ " (cowin     ) " GUICOLOR _cowin      get cowin      
		@ 10,12 say msgtext(172)+ " (cowinget  ) " GUICOLOR _cowinget   get cowinget   
		@ 11,12 say msgtext(173)+ " (corahmen  ) " GUICOLOR _corahmen   get corahmen   
		@ 12,12 say msgtext(174)+ " (cobrowse  ) " GUICOLOR _cobrowse   get cobrowse   
		@ 13,12 say msgtext(175)+ " (comenue   ) " GUICOLOR _comenue    get comenue    
		@ 14,12 say msgtext(176)+ " (coerr     ) " GUICOLOR _coerr      get coerr      
		@ 15,12 say msgtext(177)+ " (comsg     ) " GUICOLOR _comsg      get comsg      
		@ 16,12 say msgtext(178)+ " (coftabez  ) " GUICOLOR _coftabez   get coftabez   
		
		
		
		// diese zwei gets werden ion der Datenbank geschrieben
		@ 17,12 say msgtext(179)+ " (coftatext ) " GUICOLOR _coftatext  get unisystem->coftatext
		@ 18,12 say msgtext(180)+ " (comemo    ) " GUICOLOR _comemo     get unisystem->comemo
		read

		replace cobs        with strtran(cobs      ,'-','0');
				cosayget    with strtran(cosayget  ,'-','0');
				cosayinget  with strtran(cosayinget,'-','0');
				coueb       with strtran(coueb     ,'-','0');
				cowin       with strtran(cowin     ,'-','0');
				cowinget    with strtran(cowinget  ,'-','0');
				corahmen    with strtran(corahmen  ,'-','0');
				cobrowse    with strtran(cobrowse  ,'-','0');
				comenue     with strtran(comenue   ,'-','0');
				coerr       with strtran(coerr     ,'-','0');
				comsg       with strtran(comsg     ,'-','0');
				coftabez    with strtran(coftabez  ,'-','0');
				coftatext   with strtran(coftatext ,'-','0');
				comemo      with strtran(comemo    ,'-','0')

		unlock

		commit
		
		_colorinit()
	endif

return
Danke :)

Re: kein update auf Datenbank

Verfasst: Sa, 09. Jan 2016 12:56
von Tom

Code: Alles auswählen

Select unisystem
vor dem ersten Get. Innerhalb der Get-Read-Systematik darf es dann aber keinen weiteren Wechsel der Workarea geben.

Re: kein update auf Datenbank

Verfasst: Sa, 09. Jan 2016 12:57
von rsz
Tom, meinst du "select" mit workarea?

so wie der Code ist werden nur die letzten zwei Felder in die DB geschrieben.
in den Anderen geht die Eingabe sofort nach verlassen des Feldes verloren und wird auch gar nicht mehr angezeigt.

Wenn ich die Anweisung "Fields ..." vor die Get's schreibe klappt das auch. irgendwie scheint der get nicht zu wissen wohin mit der Einagbe :O

LG,
Ralf

Re: kein update auf Datenbank

Verfasst: Sa, 09. Jan 2016 13:15
von Tom
Kann es sein, dass Du PRIVATEs oder gar PUBLICs mit den gleichen Namen wie die Feldnamen hast?

Re: kein update auf Datenbank

Verfasst: Sa, 09. Jan 2016 13:24
von Rudolf
Hallo,
vorher sind noch Funktionen die die Workarea ändern könnten, probier mal ? select() vor den gets. Ich stelle IMMER vor der Datenbankvariablen den Alias, ist besser zu lesen und viel sicherer.

Grüße
Rudolf

Re: kein update auf Datenbank

Verfasst: Sa, 09. Jan 2016 14:03
von rsz
Hallöchen :)

der select() zeigt 3 an, ist eigentlich die richtige DBF.

wäre es die falsche dbf/select, würden ja aber die Werte nicht stimmen die der get anzeigt (bei änderungen)

verstehen kann ich es nicht, ich werde mich mal mit der "fields"-Anweisung (vor den GETs) oder dem Alias-> davor vortasten...

in clipper gab es da nie Probleme :(

Danke, LG,
Ralf

PS: habs vergessen:
dies zeigt mir alle Angaben korrekt, dbf, Alias, select is völlig OK!

@ 04, 01 say select()
@ 04, 21 say alias()
@ 04, 41 say dbf()
wait

Re: kein update auf Datenbank

Verfasst: Sa, 09. Jan 2016 14:34
von Jan
Hallo Ralf,

ich selber nehme cAlias-> statt FIELD->. Das macht das Code lesen sehr viel einfacher, weil Du dann sofort siehst, welche dbf gerade angesprochen wird. Und Du kannst Dir teilweise das Select(i) sparen, da ja klar ist, wohin der Wert geschrieben werden soll. Egal welcher Select gerade aktiv ist.

Jan

Re: kein update auf Datenbank

Verfasst: Mo, 11. Jan 2016 7:46
von brandelh
auf jeden Fall ist es sicherer den select unisystem direkt vor dem GET zu setzen.

Wenn die Clients auf Win7 basieren kann es aber auch ein Problem mit der Registry sein (Dafür hat Alaska einen Patch veröffentlicht).
Alle Dateibasierten Systeme haben ein Problem mit den neuen Cachewerten für Infos für Remotedateien.

Aber wir sind bei Flagship oder ?

Link und Suchbegriffe

http://www.xbaseforum.de/viewtopic.php? ... try#p92235

Re: kein update auf Datenbank

Verfasst: Mo, 11. Jan 2016 9:45
von Tom
Wie gesagt: Wenn es Variablen mit den gleichen Namen gibt, haben diese Vorrang:

Code: Alles auswählen

name := Space(10)
USE test NEW // enthält ein Feld "name"
DbGoTop() // "name" ist im ersten Datensatz "Müller"
@ 1,1 GET name // Du wirst hier 10 Leerzeichen sehen
@ 2,1 GET test->name // und hier "Müller"
Lass Dir mal vermeintliche Feldinhalte anzeigen, bevor die Tabelle geöffnet wird. Vielleicht sind sie bereits definiert.

Re: kein update auf Datenbank

Verfasst: Mo, 11. Jan 2016 10:03
von brandelh
war die Reihenfolge nicht FELD geht vor MEMVAR ... da ich seit Ewigkeiten keine PRIVATES mehr nutze und immer mit Aliasbezeichner arbeite bin ich mir nicht mehr sicher,
aber so lese ich das in der Hilfe
In der Programmierpraxis hat sich die Konvention durchgesetzt, daß Feldvariablen in der Regel nicht, Speichervariablen aber immer deklariert werden. Feldvariablen sind immer dynamische Variablen und zur Laufzeit wird im Zweifel auf eine Feldvariable zugegriffen (Ausnahme: durch den Compiler-Schalter /V wird im Zweifel auf eine Speichervariable zugegriffen). Ein sicherer und eindeutiger Zugriff auf Feldvariablen erfolgt in der Regel mit Hilfe des Alias-Operators, der speziell für die Programmierung mit Feldvariablen vorgesehen ist.
Da dies Verhalten schon bei Clipper so war, müsste es auch bei Flagship so sein ...

Re: kein update auf Datenbank

Verfasst: Mo, 11. Jan 2016 10:25
von Tom
Stimmt. Wenn ich das hier mit Xbase++ mache, wird zweimal "Müller" angeboten:

Code: Alles auswählen

FUNCTION Main()
LOCAL aStru := {{'name','C',30,0}}
DbCreate('test.dbf',aStru)
USE test NEW
APPEND BLANK
REPLACE NAME with 'Müller'
CLOSE DATA

name := Space(10)
USE test NEW
DbGoTop()

@ 1,1 GET name
@ 2,1 GET test->name
READ

CLOSE DATA
RETURN nil

Re: kein update auf Datenbank

Verfasst: Mo, 11. Jan 2016 11:41
von brandelh
Wichtig wären Infos über das OS des Servers (also wo die DBF gespeichert ist) und des Client-Rechners

Re: kein update auf Datenbank

Verfasst: Mo, 11. Jan 2016 13:42
von rsz
Hallo Jungs :)

vielen Dank für die Antworten, hier mal ein paar Infos zum aktuellen Stand:

- Workarea ist korrekt, es gibt keine Variablen mit gleichem Namen!
- der "say" funktioniert ja auch ohne alias :?: die korrten Daten werden angezeit, nur der "get" funktioniert nicht - kein Update nach Dateneingabe.

ich arbeite auf windows 8.1, Daten sind local wie die sourcen auf E: (HDD)

Ich bin dabei vor jeden Get den Alias zu schreiben, habe ich ja auch schon bei Daten außerhalb der aktuellen Workarea.
Scheint mir am sichersten und sieht gut aus!

@Tom: so habe ich es auch erwarter, 2xMüller - entsprechend ist der Code aufgebaut - innerhalb der Workarea ohne alias->

Danke Euch :D :D :D

melde mich wenn ich etwas anderes herausfinden sollte...

Re: kein update auf Datenbank

Verfasst: Mo, 11. Jan 2016 14:30
von brandelh
Kann es sein, dass Flagship die GETs puffert ?
änderst du den Select Bereich in einer Funktion zwischen GET (=> Definition) und READ ( => tatsächliche Ausführung ! ) ...

Re: kein update auf Datenbank

Verfasst: Fr, 15. Jan 2016 11:22
von paulberger
Hallo Tom,
Tom hat geschrieben:Wie gesagt: Wenn es Variablen mit den gleichen Namen gibt, haben diese Vorrang
Sowohl in FlagShip als auch in Clipper haben Felder (der aktuellen oder alias-> Datenbank) Vorrang vor gleichnamigen PUBLIC, PRIVATE und auto-PRIVATE Variablen. Die LOCAL und STATIC Variablen haben stets Vorrang vor PUBLIC, PRIVATE und Felder ohne Alias, mit FIELD alias oder Deklaration kann jedoch Feld-Vorrang erzwungen werden. Eine PARAMETER Deklaration wird wie PRIVATE behandelt, Parameter einer UDF (in Klammern) als LOCAL. Während des READ können natürlich unterschiedliche Datenbanken (d.h. nicht nur die aktuelle dbf) verwendet werden, wenn die Felder mit dem alias-Namen (meinedbf->feldname) referenziert sind. Das modifizierte Beispiel von oben veranschaulicht dies:

Code: Alles auswählen

FUNCTION Main()
private name := "müller priv"
local vorname := "hugo local"
LOCAL aStru := {{'name','C',30,0}, {'vorname','C',30,0}}

set font "courier", 12
oApplic:Resize(25,110,,.T.)

DbCreate('test.dbf',aStru)
USE test NEW
APPEND BLANK
REPLACE NAME with 'Müller Rec1', vorname with "peter Rec1"
APPEND BLANK
REPLACE NAME with 'Name Rec2', vorname with "Vorname Rec2"
CLOSE DATA

// name := Space(10)
USE test NEW
DbGoTop()

@ 1,1 SAY "name          " GET name
@ 2,1 SAY "test->name    " GET test->name
@ 3,1 SAY "m->name       " GET m->name
@ 4,1 SAY "vorname       " GET vorname
@ 5,1 SAY "field->vorname" GET field->vorname
@ 6,1 SAY "test->vorname " GET test->vorname
READ
setpos(7,0)
? "List", dbf()
list
?
go top
while !eof()
   ? "Felder: NAME=[" + name + "] VORNAME=[" + vorname + "] != [" + test->vorname + "]"
   skip
enddo
CLOSE DATA
?
? "Variablen: NAME=[" + name + "] VORNAME=[" + vorname + "]"
wait
RETURN nil
Paul

Re: kein update auf Datenbank

Verfasst: Fr, 15. Jan 2016 12:43
von Tom
Hallo, Paul.

Hatte ich schon selbst korrigiert (siehe Testcode drei Nachrichten rückwärts).

Re: kein update auf Datenbank

Verfasst: Do, 31. Mär 2016 12:39
von rsz
Hallo zusammen,

ich wollte mich noch mal melden und eine Erkenntniss weitergeben, zum obigen Thema:

Scheinbar ist da ein dicker Bug in flagship: Dieses Verhalten tritt nur auf wenn eine "Relation" gesetzt ist!
Ohne "set Relation" werden die Inhalte der Get-Felder einwandfrei angezeigt und die DB erfährt auch einen Update!

Wenn es hierzu keine Systemeinstellung gibt, handelt es sich um ein echten Bug in flagship.

Wollte ich nur loswerden :)

LG aus dem ENDLICH sonnigen Brühl,
Ralf

Re: kein update auf Datenbank

Verfasst: Fr, 08. Apr 2016 15:39
von paulberger
In deinem Source-Listing vom 09. Jan 2016 ist keine SET RELATION enthalten, deshalb ist dies nicht nachvollziehbar :roll:
Natürlich kann man auf die abhängige Datenbank mittels Alias->FeldName zugreifen, auch im @..GET