F18

ovo je najbolje da izdvojim na poseban tiket

Pobrisao sam lokalne dbf-ove

• pos_osob.dbf
• pos_strad.dbf

i ušao u aplikaciju / ušao u POS

nakon što sam izašao provjerio stanje dbf-ova, dbf-ovi su napunjeni sa stanjem iz sql-a to je dobro, međutim problem je kada uđem ponovo u POS i pokušam ući u OSOB ili STRAD, dobijam grešku

segmentation failed

nakon što ponovo uđem u aplikaciju, dbf-ovi (ova dva) se isprazne i onda mogu ući u njih ali su prazni.

Čudno, idem vidjeti šta je to ?

ove wa se preklapaju sa RNAL

#define F_ARTICLES  142

da li se desi da nakon

pos inicijalizacije uđe u rnal inicijalizaciju i onda se napravi full sycnhro (zap) koji sve pobriše u pos dbf-ovima

svakako treba sve ove WA napraviti jedinstvenim

uradi to odmah za kompletan f_fmk.ch

segmentation fault je bila greška ranije kada smo imali dvije tabele pod istim brojem...

F_STRAD

pa onda opet imamo tabelu rnal-a

F_ARTICLES

to je sigurno greška

jeste jeste, to je to

Svojevremeno si pominjao da se u harbour-u mogu zadavati i oznake, recimo

#define F_ARTICLES "rnal_articles" 

Saša Vranić je napisao/la:

Svojevremeno si pominjao da se u harbour-u mogu zadavati i oznake, recimo

[...]

da ali logika je da se WA tretira na najvećem broju mjesta kao numerička varijabla.

ma samo prođi kroz kompletan f_fmk ... pravi rupe između pojedinih modula u numeraciji ako se naknadno budu dodavale tabele

ok

po ovom principu:

F_SUBAN 1
F_ANAL 2

F_SIF1  21
F_SIF2  22

F_FAKT 41
F_DOKS 42 

ali mislim da ih ima više od 250

ja sad ne znam da li harbour dozvoljava više od 250, ja sam negdje već koristio i 300 ali negdje mi nije uspjevalo sa 350 recimo

Ernad Husremović je napisao/la:

po ovom principu:
[...]

ma jasno

#27370 sredio radna područja

interesantno segmentation se opet dešava ?!???

Znači pobrisao lokalne tabele i ušao u app i kada pokušam u jednu od ove dvije tabele izbaci me odmah...

Sve ostale tabele rade kako treba.

ja sam dobio ovu grešku:

====================================================================================
F18 bug report (v3.2) : 02.04.12 13:58:03
====================================================================================
Verzija programa: 0.9.91 29.03.2012 1.9.90

SubSystem/severity    : BASE          2   
GenCod/SubCode/OsCode :         14       1003          0   
Opis                  : Variable does not exist
ImeFajla              :   
Operacija             : RECI_GDJE_SAM
Argumenti             : NIL 
canRetry/canDefault   : .T. .F. 

CALL STACK:
--- --------------------------------------------------------------------------------
  1 (b)F18_INIT_APP / 103 
  2 UPDATE_REC_SERVER_AND_DBF / 50
  3 CREPOSISIFDATA / 85
  4 POS_INIT_DBFS / 24
  5 TPOSMOD:MMENU / 82
  6 TPOSMOD:RUN / 149 
  7 MAINPOS / 30
  8 MAIN / 67
--- --------------------------------------------------------------------------------

vjerovatno se ne učitava fmk.ch u kome se definiše ovaj "#define"

ranije mi je prijavlijvao da strad nema na serveru trebam nover baze ?

Nema šta, svaki put kada ulazim u šifranik praktično ova dva šifrarnika budu prebrisana, znači kada god se desi

O_STRAD

O_OSOB

odradi update fmk paketa svakako

err qry: DELETE FROM fmk.strad WHERE id='0'err msg:ERROR:  relation "fmk.strad" does not exist
LINE 1: DELETE FROM fmk.strad WHERE id='0'
                    ^

DELETE FROM fmk.strad WHERE id='0'

iako nema tabele gornji potvrđuje moju sumnju:

WHERE id='0'

update_rec_and_server bi trebao uraditi nešto sa ovim poljima - uraditi rpad

ovo je opasno što radi

ovo bi vrlo lahko i moglo biti ono što je uzročnik problema u semaforima ver 1.0

napravio sam punjenje ovih tabela na dužinu polja

commit

ovo se desi u log-u

DELETE FROM fmk.strad WHERE id='0 '      <<<<<<<<< ok
_sql_query VALTYPE(_ret) = O

DELETE FROM fmk.strad WHERE id='  '      <<<<<<<< zašto ovo ?????
_sql_query VALTYPE(_ret) = O

INSERT INTO fmk.strad(id,naz,prioritet) VALUES('0 ','Nivo adm.      ','0')
_sql_query VALTYPE(_ret) = O
push ids: STRAD / (array): 1 / 0  ; 2 /    ; <<<<<<<<<< ok

DELETE FROM fmk.strad WHERE id='1 '   <<<<<<<< ok
_sql_query VALTYPE(_ret) = O

DELETE FROM fmk.strad WHERE id='  '   <<<<<<<< opet prazan ?????
_sql_query VALTYPE(_ret) = O

INSERT INTO fmk.strad(id,naz,prioritet) VALUES('1 ','Nivo upr.      ','1')
_sql_query VALTYPE(_ret) = O
push ids: STRAD / (array): 1 / 1  ; 2 /    ; 
DELETE FROM fmk.strad WHERE id='3 '
_sql_query VALTYPE(_ret) = O
DELETE FROM fmk.strad WHERE id='  '
_sql_query VALTYPE(_ret) = O
INSERT INTO fmk.strad(id,naz,prioritet) VALUES('3 ','Nivo prod.     ','3')
_sql_query VALTYPE(_ret) = O
push ids: STRAD / (array): 1 / 3  ; 2 /    ; 
COMMIT;

_sql_query VALTYPE(_ret) = O

BEGIN;
_sql_query VALTYPE(_ret) = O
DELETE FROM fmk.osob WHERE id='0001'
_sql_query VALTYPE(_ret) = O
DELETE FROM fmk.osob WHERE id='    '
_sql_query VALTYPE(_ret) = O
INSERT INTO fmk.osob(id,naz,korsif,status) VALUES('0001','Admin                                   ','╬¤ËĎ┴đ','0 ')
_sql_query VALTYPE(_ret) = O
push ids: OSOB / (array): 1 / 0001 ; 2 /      ; 
DELETE FROM fmk.osob WHERE id='0010'
_sql_query VALTYPE(_ret) = O
DELETE FROM fmk.osob WHERE id='    '
_sql_query VALTYPE(_ret) = O
INSERT INTO fmk.osob(id,naz,korsif,status) VALUES('0010','Prodavac 1                              ','áááá▒đ','3 ')
_sql_query VALTYPE(_ret) = O
push ids: OSOB / (array): 1 / 0010 ; 2 /      ; 
DELETE FROM fmk.osob WHERE id='0011'
_sql_query VALTYPE(_ret) = O
DELETE FROM fmk.osob WHERE id='    '
_sql_query VALTYPE(_ret) = O
INSERT INTO fmk.osob(id,naz,korsif,status) VALUES('0011','Prodavac 2                              ','áááá▓đ','3 ')
_sql_query VALTYPE(_ret) = O
push ids: OSOB / (array): 1 / 0011 ; 2 /      ; 
COMMIT;

_sql_query VALTYPE(_ret) = O

ERR check_recno OSOB cnt: 3 / fmk.pos_osob cnt:0        <<<<<<<<<<<<<<<<<<< čekiranje

qry: SELECT id,korsif,naz,status FROM fmk.pos_osob ORDER BY id LIMIT      15000 OFFSET          0

pos_osob updated from sql server rec_cnt: 0

ERR check_recno STRAD cnt: 3 / fmk.pos_strad cnt:0    <<<<<<<<<<<<<<<<<<<<<<<<<<<< interesantno

qry: SELECT id,naz,prioritet FROM fmk.pos_strad ORDER BY id LIMIT      15000 OFFSET          0
pos_strad updated from sql server rec_cnt: 0

sad vidim neku zbrku, na sql/db imam i

• pos_osob
• osob

• pos_strad
• strad

evo šta fmk paket sadrži !

bringouts-MacBook:fmk bringout$ grep -i -R "osob" *

database/misc/pos.sql:CREATE TABLE IF NOT EXISTS fmk.pos_osob
database/misc/pos.sql:DROP INDEX IF EXISTS pos_osob_id1;
database/misc/pos.sql:DROP INDEX IF EXISTS pos_osob_id2;
database/misc/pos.sql:CREATE INDEX pos_osob_id1 ON fmk.pos_osob( korsif );
database/misc/pos.sql:CREATE INDEX pos_osob_id2 ON fmk.pos_osob( id );
database/misc/pos.sql:GRANT ALL ON TABLE fmk.pos_osob TO xtrole;
database/misc/pos.sql:CREATE TABLE IF NOT EXISTS fmk.semaphores_pos_osob
database/misc/pos.sql:DROP INDEX IF EXISTS semaphores_pos_osob_user_code_idx;
database/misc/pos.sql:CREATE INDEX on fmk.semaphores_pos_osob(user_code);
database/misc/pos.sql:GRANT ALL ON TABLE fmk.semaphores_pos_osob TO xtrole;

bringouts-MacBook:fmk bringout$ grep -i -R "strad" *

database/misc/pos.sql:CREATE TABLE IF NOT EXISTS fmk.pos_strad
database/misc/pos.sql:DROP INDEX IF EXISTS pos_strad_id1;
database/misc/pos.sql:DROP INDEX IF EXISTS pos_strad_id2;
database/misc/pos.sql:CREATE INDEX pos_strad_id1 ON fmk.pos_strad( id );
database/misc/pos.sql:CREATE INDEX pos_strad_id2 ON fmk.pos_strad( naz );
database/misc/pos.sql:GRANT ALL ON TABLE fmk.pos_strad TO xtrole;
database/misc/pos.sql:CREATE TABLE IF NOT EXISTS fmk.semaphores_pos_strad
database/misc/pos.sql:DROP INDEX IF EXISTS semaphores_pos_strad_user_code_idx;
database/misc/pos.sql:CREATE INDEX on fmk.semaphores_pos_strad(user_code);
database/misc/pos.sql:GRANT ALL ON TABLE fmk.semaphores_pos_strad TO xtrole;

update-ovo sam server db na 4.4.1 dbijam da ne postoji tabela fmk.strad

zar ne treba biti fmk.pos_strad ?

a ovakve stvari su takođe, pretpostavljam, potencijalne bombe

set_a_dbf_temp("pom"        ,   "POM"         , F_POM  )

ne može biti F_POS_POM itd ...

svakako staviti to u POS nema smisla.

staviti ovo barem u common da se zna da postoji alociran broj za pom (vjerovatno negdje i pom_2 ili pom2 treba)

pronašao grešku:

commit

Saša Vranić je napisao/la:

pronašao grešku:

commit

hm pa nije ovo baš greška aplikacije ovo je bug u update funkciji

ispravio tako da bi sada i alias trebao biti prihvatljiv parametar

ali treba koristiti dbf_table kao parametar uobičajeno

ažuriranje računa, povrat računa korekcije

commit

da, tabela kao parametar, ime tabele pravo