requery nakon brisanja!

Imam frku...uvije glupost kod mene.Trudio sam se sam riješit problem izvrtio sam sve živo ali neide i zato ću problem podijelit s svima na ovom forumu.
Nakon što mi kod napravi requery nakon brisanja pojedinog zapisa.Svi dotad unešeni podaci se obrišu s forme iako fizički postoje u tablici.
Tablica tbl_blagajns Ima parametre br_blagajne,red_broj,Datum,Opis,iznos,u_korist.Primarni ključ nema jer može biti više ulaza za pojedinu blagajnu.Što predlažete kako da organiziram tu jednostavnu bazu!
Na jednoj formi nalaze se command button za unos,BRISANJE,pregled I stampanje.
Cod za brisanje je
Public Function fbrisanje()

Dim strSql, t, z As String

On Error GoTo Err_fbrisanje
'Dozvoljava brisanje ,jer je u prportis forme to na false
Me.AllowDeletions = True
t = Me!Red_broj
z = Me!broj_blagajne
'Pomoću ovo sql izkaza brišem točno pozicionirani zapis brpj_blagajne i red_broj!
strSql = "DELETE * "
strSql = strSql & " FROM tbl_blagajna "
strSql = strSql & " WHERE (red_broj= " & t & ") AND (broj_blagajne=" & z & ");"
Call CurrentDb.Execute(strSql, dbFailOnError)
'Nakon ovog requerya obriše s forme sve podatke iako u tablici postoje
'kako da mi nakon toga ostanu ostali podaci
'Dali neko unboun polje povežem s tekućim brojem blagajne pa da se na njega vežu podaci????HELP!
Forms!frm_blagajna_unos.Requery


Me.AllowDeletions = False
exit_fbrisanje:
Exit Function

Err_fbrisanje:
MsgBox Err.Description
Resume exit_fbrisanje

End Function

Potpis

romano

Primarni kljuc u tvjoj tablici i te kako postoji = kombinacija polja br_blagajne,red_broj. Brze to stavi na tabelu, da nemas problema kasnije. :-)

Za brisanje - a sta ce ti kod uopste? Koliko razumem ti sam koristis aplikaciju i razumes se u Access daleko vise nego prosecsn korisnik, je li tako. Klikni na record selector na formi (ona siva traka s leve strane, gde se pojavi olovcica kad editujes rekord) i pritisni taster "Delete". I gotovo. nemas potrebe za kodom uopste.

Da li ti je forma datsheet, continuous form ili samo form, ili form-subform kombinacija? sta je formin rekordset? Kako je forma otvrena, za jedan rekord ili su svi rekordi ucitani?

Ako je to sto radis ono sto se zvalo "Knjiga Blagajne", sa listovima za svaki dan, sa po 30-40 mogucih ulaza, onda ti trebaju dve tabele, jedna koju zoves na primer ListKnjige i druga koju zoves Detalji. Svaki ListKnjige je necim jedinstveno odredjen (BrKnjige,BrLista). BrKnjige - u sucaju da imas vise fizickih knjiga istovremeno, ili kad potrosis jednu knjigu, kupis drugu pa nastavis rad. Svakom listu pripada neograniceni broj detalja. Za Detalj tabelu, PK bi bio sta god je PK u tabeli ListKnjige plus recimo RedniBroj detalja. Onda lepo napravis formu i subformu i vozis.

Ako vec pises kod, malo promeni funkciju, napravi je da bude univerzalna, dostupna i drugim formama i objektima u aplikaciji. Obrati paznju na deklaraciju varijabli, svaka mora da se deklarise po tipu zasebno, grupna deklaracija tipa nije podrzana u Accessu.



Kod sam ti napisao samo da ti skrenem paznju na neke lepe manire i korisne navike pri pisanju. I dalje mislim da ti kod za brisanje rekorda sa forme absolutno nije potreban. Izbegnes sve ve probleme oko refreshovanja forme i slicno. I ne zaboravi da postavis PK na tabelu. PK moze da bude i slozen, dva ili vise polja koja zajedno jedinstveno odredjuju rekord.

Srecno :-)

Kao prvo zahvaljujem se na odgovoru!
Za ovakav način brisanja nisam znao (pozicioniranje na traženi recordset i pomoću delete +enter),to je SUPER.U budućnosti će mi Odlično doć.
A princip dvostrukog ključa nisam nikad koristio ali vidim da je odličan kod ovakvih stvari(gdje za jedan račun unosim više elemenata).Uvelike smanjuje mogućnost greške.
Možda moja organizacija blagajne pomogne i drugima na ovom forumu(možda ima još knjigovođa koje žele nešto napravit sami u accessu!)
Evo nakon tvojeg odgovora ja sam se dao na posao i napravio sam ono što sam htio!
Organizirao sam bazu na principu forme i subforme i dvija tablice i to "tbl_listknjige" i "tbl_elementi".
Unutar toga imam polja"tbl_listknjige" broj_blagajne,opis i saldo i tu je PK broj_blagajne
te
"tbl_elementi" broj_blagajne,red_broj,Opis,Kome_svrha,datum.ulaz,izlaz., gdje imam dvostruki PK broj_blagajne i red_broj!
Ovim povezivanjem sam riješio 70 % problema koje su me mučila u prošloj verziji(bez PK i samo s jednom tablicom).
Nakon svega toga treba samo još napravit forme za unos,editiranje ....,obavezno proceduru za radnu godinu ,masku za unos stranke te reporte(blagajničko izvješće i uplatnicu isplatnicu)!

Problem mi je još samo prijhenos stanja(SALDA) s jednog lista na sljedeći.On je postavljen u novoj temi pa ako tko zna molio bih da mi pomogne!
Hvala!

Potpis

romano

Nisam video novu temu, pa hajd da probamo ovde. Nemam puno vremena pa ti samo napominjem da je problem prenosa slada sa strane na stranu resiv. Vidi u bazi znanja Correlated Queries, running sum queries i slicno. Ako ti treba samo za report, mozes sa running sum da probas, to sigurno ide.

Ono sto NEMOJ da radis je da racunas saldo po stranici na kraju dana pa da to negde cuvas u bazi. Pre ili kasnije nesto nece biti sinhronizovano, a i mnogo je tesko da se odradi programski. Znam da ima ljudi na forumu kojima to nije tesko, ali to ne znaci da je resenje preporucljivo. Strpi se dan dva, ili probaj sam, pa da vidimo sta ce da ispadne.

:-)

Prijenos salda s lista na list sam riješio s izračunoim u jednom modulu.
Kao što si i sam rekao to je dosta delikatno jer sam primjetio u nekim slučajevima ne obračuna kako treba(recimo odmah po unosu ili mijenjanju),a i kod se (pre)često mora upotrebljavat.
I ja sam pobornik čim manje izračunavanja i zapisivanja u bazi podatak koji se često mijnjaju(jer nekiu put treba napravit promijene u listu blagajne za koji je već preneto stanje u saldo).
Ljepo je kad uneseš šim manje podataka a pomoću upita i drugih alata dobiješ puno informacija.
Pa ako te ne mrzi volio bih da mi daš smjernice za riješenje ovog mog PROBLEMA ,jer ovako lutam bespućima accessa!Naravno kad budeš imao vremenai ja baš nemam previše vremena(sad je udarno-završni računi).
Pozdrav i hvala

Potpis

romano

Ovako: svrha saldiranja po stranici i prenos na sledecu stranu jeste olaksavanje rucnog racunanja. Neka su listovi knjige oznaceni sa 1,2,3,....N

Neke na prvom listu nema prenosa sa prethodnog lista. Saldo na dnu lista bice

List 2 imase prenos sa lista 1, a to je [Saldo na dnu ista 1], n apozitivnoj strani, kao neki pocetni Ulaz.
Saldo na dnu lista 2 bice:

Za list 3 imacemo:

Sada uoci pravilnost:

Kveri koji racuna sume ulaza/izlaza za zadati list X je jednostavan:

Ako mu dodamo neke delove dobijemo sve sto nam treba:

Poslednji kveri ima sve sto ti treba - sume po pojedinim listovima i sume ulaza i izlaza na svim prethodnim listovima. Dalje znas i sam.

Trik je upotrebiti 'subqueries' ili 'embedded queries' ili 'kveri unutar kverija'. Posto su i vanjski i unutrasnji kveriji na istoj tabeli, moramo da upotrebima 'alias names' - A i B.

Na formama mozes da upotrebis DSUM, na primer:


Za reporte je bolje koristiti kveri, DSUM je dosta sporo da se izvrsava za svaki rekord. Na formi je OK jer se izvrsava samo jednom. Pa jos ako to spakujes u Form Footer, eto ti Saldo na dnu ekrana. Samo ponekad pritisnes F9 da osvezis rezultat, ili na Form_AfterUpdate za subformu stavis Parent.requey ili nesto slicno i ne treba ti F9.........

Dost je za nekoliko dan, sta mislis?

;-)