Totalno ludilo - random pojavljivanje vrednosti iz baze podataka

Imam Firebird bazu podataka, i u njoj tabele sa timestamp poljima.
Kada otvorim dataset, u tim kolonama mi se pojavljuje nesto sto nema blage veze sa zivotom. Datum je dobar, ali vreme nije. ispisuje se neko vreme koje ne postoji nigde u tabeli, a onda se to isto vreme ponovi proizvoljan broj puta (3, 5, 10, 20...), pa opet vreme koje ne postoji u tabeli i tako u krug. DisplayFormat je u redu.

Sad nastupa ludilo:

Pomislim da je baza ostecena - ali ako otvorim tabele sa bilo cim drugim (nekim alatom za administraciju, ili napisem program koji ce samo da otvori tabelu), sve je u redu - vrednosti se prikazuju ispravno.

Pomislim da su u pitanju komponente - zamenim IBX sa FibPlus komponentama (ovo je potrajalo), i ponovo isto...

Pomislim mi neki memory leak unistava delove programa - uklonim sve sve dinamicke strukture koje nisu neophodne, one druge proverim dvesta puta, proverim oslobadjanje memorije, obavezno postavim pointere na nil, itd... Opet nista.

Ovo traje jako dugo, ja nemam vise ideja, bilo kakav tip bi bio od neizmerne koristi. Ljudi dajte bilo sta... Ocu da izlupam sve ovo u pic^%#@*&%&*(@#U%

Govori tiho i nosi psa sa sobom...

kolika je velicina te tabele (u KB, ili MB). Mozda bi mogao da je izdvojis (sa nekoliko zapisa iz te tabele, narocito sa problematicnim zapisima), i da je okacis ovde.... parce koda za upis, pristup podacima tabele bi dobrodosao...

poz.

Najgore je sto nema nista spicificno u bazi. Mala je, oko 5 MB, ima samo pet tabela, tipovi polja su INTEGER i TIMESTAMP. Po SQL Monitoru, podaci iz baze izadju ispravni, ali iz nekog razloga, Delphi, kada pretvori TIMESTAMP u DateTime, tj Double, smanji preciznost ovog tipa, i svi TIMESTAMP-ovi u nekom opsegu se interpretiraju kao isti datum i vreme.
Da li postoje neki switch-evi kompajlera koji uticu na preciznost Double promenljivih?

Sa sledeceg linka: http://www.vitavoom.com/Produc...ress_Driver/docs/appendix.html
nasao sam ovo... mozda pomogne ;)

I'm having problems with queries with timestamp/datetime fields.

The problem is caused by a dbExpress™ VCL/CLX bug. There is an interface called ISQLCursor.isSearchable() making an update query, and that would create a statement that would have a non-existent value, like this:

update test set b = '2002-08-02 18:36:50' where b = '2002-08-02 18:36:52';

Obviously PostgreSQL will not be able to find the b value from the WHERE clause, and a exception message like this will be raised:
Record not found or changed by another user

To solve this, use a primary key/index and the UpdateMode to upWhereKeyOnly mode with keys on fields that are not timestamp/ datetime/etc (do not make the timestamp values indexed). This will keep VCL/CLX from generating a wrong WHERE statement.

If in your database these fields are indexed, removing the pfInWhere option from the TField.ProviderFlags property for that field should be enough. If the actual value in your table that have no fraction or timezone value values, the generated SQL will be able to find that record (because it will use only the indexed fields in the WHERE clause, and the update will suceed.

Another way of solving this issue is by using a view using the date_trunc function, like this:

create view TestView as select a, date_trunc('second', b) as b from test;

and then create a rule to INSERT/UPDATE/DELETE rows, but this method is more complicated.

The pgExpress Suite does not suffer from this problem since it maps the fields to custom types. Just to document, the Delphi 7 Readme.txt file has a similar "Known Issues" note for the DB2™ dbExpress™ driver.

kao i sledece : http://mc-computing.com/Databases/Delphi/Firebird/Dates.html


DateTimeToStr fails
This code fragment fails because of how the time is formatted.

DateTime := DateTimeToStr(Now);

// CREATE TABLE "xyz_tbl" (
// "xyz_ID" VARCHAR(5) NOT NULL /* "Experiment_ID" */ ,
// "Date_Time" TIMESTAMP /* "Date_Time" */
// );

s :=
'INSERT into "xyz_tbl" ' +
'("xyz_ID", "Date_Time")' +
' Values (''' +
Experiment_ID + ''', ''' +
DateTime + '''' +
' ) '
;
ExecuteSQL(s); // a routine I wrote

On my system

LongTimeFormat = 'h:mm:ss AMPM'

which produces the standard 12 hour clock format

'1/30/2005 3:06:32 AM'

that fails with Firebird.

Notice that LongTimeFormat uses mm for both month and minutes, but that nn always produces minutes. From the Delphi help

mm Displays the month as a number with a leading zero (01-12).
If the mm specifier immediately follows an h or hh specifier,
the minute rather than the month is displayed.

Tests indicate that LongTimeFormat is not a system variable, meaning that once you change its value, you do not have to restore it. In other words, changes made by your program only affect your program.

Here are some miscellaneous instructions used to format date/times

DT_Str := Date + ' ' + Time;
DT := StrToDateTime(DT_Str);
DateTimeToString(DT_Str, 'mm/dd/yyyy hh:mm:ss am/pm', DT);// ok for display, not for Firebird
DateTimeToString(d, 'yyyymmdd', DT);
DateTimeToString(m, 'yyyymmdd_hhnnss', DT);

pozdrav!

Provalio sam u čemu je problem. U aplikaciji koristim DirectX, i on, da bi brže računao sa brojevima u pokretnom zarezu, smanjuje preciznost rada sa njima. Funkcija kojom ovo radi je Set8087CW. Ovo je podesavanje na nivou programa. Posto aplikacija veoma intenzivno koristi grafiku, ne dolazi u obzir menjenje ovog podešavanja (operacije su i do tri puta sporije), pa je jedino resenje bilo SUBSTR(CAST(VREME as VARCHAR(25)), 1, 19), a pristupanje podacima iz tabela preko stored procedura ili pogleda. Pošto je u pitanju mali broj tabela, ovo je prihvatljivo resenje. Interesantno je da se gubitak preciznosti odražava samo na TIMESTAMP, ali ne i na srodna TIME polja.

@obucina

Trenutno se mlatim sa DirectX + baza, dakle imamo istih problema :(

Ako imate vremena, moj email : [email protected]

poz.

Joj, nemoj mi Vi, molim te... Ja sam jos malo pa punoletan... Salim se, naravno, ali se osecam tako - imam jedno 17 godina, ali po licnoj - 28.

Jel te zanima nesto konkretno ili samo da razvezem pricu? Da predjemo na privatne poruke?