Hej igen!
Har ett formulär med en mängd fält som uppdateras via formuläret.
När ett visst villkor inträffar, så önskar jag uppdatera ett antal fält i samma tabell vars fält är tillgängliga i formuläret. De fält jag då önskar uppdatera har jag däremot inte med i formuläret pga att det redan innehåller så många fält att jag i så fall skulle överskrida gränsen för antal fält i formuläret.
Jag använder då en rutin enligt nedan där jag gör uppdateringarna

Set PersonRecord = New ADODB.Recordset
PersonRecord.Open "SELECT * FROM Personer WHERE PAnstallningsnr = " & tmpAnstallningsnr, CurrentProject.Connection, adOpenKeyset, _
adLockOptimistic, adCmdText
PersonRecord.Fields("PManadsUppgnr") = ManadsUppgnr
PersonRecord.Fields("POmbordDagarFrAretsBorj") = PersonRecord.Fields("POmbordDagarFrAretsBorj") + OmbordAntaldagar
….
….
PersonRecord.Update

Så långt fungerar det hela OK!
Problemet är att när jag sedan vill stänga formuläret så får jag meddelandet:

”DENHÄR POSTEN HAR ÄNDRATS AV EN ANNAN ANVÄNDARE SEDAN DU BÖRJADE REDIGERA DEN.
OM DU SPARAR POSTEN KOMMER DEN ANDRA ANVÄNDARENS ÄNDRINGAR ATT GÅ FÖRLORADE. Osv …..

Nu undrar jag därför hur jag skall gå tillväga för att få med både de ändringar jag inför via
PersonRecord.Update och de ändringar som införts via fält i formuläret som är kopplade till samma tabell. ?
Tacksam för svar/ Harry

Testa att spara förändringen i formuläret först. Såhär har jag gjort det i Access 95, är dock lite osäker på om det fungerar fortfarnade.

DoCmd.DoMenuItem 0, 5, 4, 0, acMenuVer70 ' Formulär, Poster, Spara post

/Johan

Hej Johan!
Oavsett var jag lade in DoCmd.DoMenuItem 0, 5, 4, 0, acMenuVer70 ' Formulär, Poster, Spara post
så fick jag felmeddelandet:

Körfel '2046'
Kommandot eller instruktionen 'SparaPost' är inte tillgängligt nu.

Jag antar att man på nåt sätt borde komma åt den ".Open instruktion" som används när formuläret öppnas så att man där fick laborera med "LockType".

enligt:
recordset.Open Source, ActiveConnection, CursorType, LockType, Options

mvh/Harry

Det var länge sedan jag pysslade med Access, men man kommer väl åt recordsetet som formuläret bygger på, kan du inte uppdatera det istället?

/Johan

Hej Johan!
Jo det gick att komma åt recordsetet som formuläret bygger på.

Kunde konstatera att Lock Type är Optimistic vilket innebär bl.a att meddelandet om konflikt ges om fler än en användare uppdaterat aktuellt rekord.
Problemet är alltså att instruktionen Record.Update räknas som en annan användare.

Tycker det vore konstigt om det inte fanns en lösning på dethär problemet.
Det kan ju knappast vara någonting unikt eller ovanligt att man vid redigering av fält via ett formulär kommer till en situation där man vill uppdatera fält i samma post, men som inte finns med i formuläret.
I mitt fall gäller det att jag vill addera innehåll ur fält till sk. statistikfält där jag samlar in uppgifter med värden samlade från årets början. (Finns dessutom ingen anledning att ta med de fälten i formuläret).

mvh/Harry

Varfö använda recordset? Om fältet fins med i frågan men inte är bundet till en kontroll går det fortfarande att accessa det:

Private Sub Combo0_AfterUpdate()
    Me("PManadsUppgnr") = ManadsUppgnr
    Me("POmbordDagarFrAretsBorj") = Me("POmbordDagarFrAretsBorj") + OmbordAntaldagar
End Sub

Hej Andreas och tack för ditt förslag!
Förslaget är en riktigt smart och användbar lösning, men
i mitt fall kan jag inte använda lösningen denhär gången.
Orsaken är den att jag redan har så många fält definierade så att jag får meddelandet
" FÖR MÅNGA FÄLT DEFINIERADE " när jag lägger till mina s.k. statistikfält (De är ca 25 st till antalet).
I det aktuella formuläret hanterar jag fält från 3st tabeller.

Ett förslag till lösning är att jag skapar en ny tabell för mina statistikfält och hanterar den tabellen enbart via recordset.
Helst skulle jag vilja ha statistikfälten också i min "PersonTabell", men då uppstår mitt problem med att uppdatera fälten.

mvh/Harry

Hur ser din datastruktur ut? Kanske bör förändra den.

Systemet jag bygger är ett lönesystem för fartygspersonal.
Jag använder Tabell:
Personuppgifter( adress, löneuppg, skatteuppg. mm)
Månadsuppgifter( för uppgifter om arbetsinsatser per månad (ombord arbeten, osv)
Parameteruppgifter( lönekonstanter osv)
samt ett mindre antal tabeller innehållande befattningskoder, olika statusuppgifter mm)
Datastrukturen jag använder är den enklaste tänkbara.
Jag kopplar ihop tabellerna (där så är tillämpligt (Personuppg->Månadsuppg) via pekare Anställningsnummer).
Månadsuppgifterna kan bestå av en eller flera Månadsuppgifter per månad (jobb på ett eller fler fartyg under den gångna månaden) därför numrerar jag Månadsuppgifterna så att nummern samtidigt skall kunna fungera som en pekare framåt bakåt vid begäran av t.ex lönebesked för viss period).

Verkar som om den rätta lösningen på mitt problem är att införa en ny tabell Statistikuppgifter, som också länkas via anställningsnummer och månadsuppgiftsnummer.
Ovanstående lösning gör att jag även slipper uppdateringsproblemet av personregistret även om det skulle vara intressant rent tekniskt att få reda på hur det problemet kunde lösas.
Lämnar därför tråden öppen ett tag till.

Är givetvis intresserad av hur andra lösningar eller datastrukturer kunde se ut.

mvh/ Harry

Har du verkligen 1000+ kontroller på ditt formulär? Råkade ut för problemet med att access klagade på att jag hade för många kontroller på mitt formulär trots att jag totalt hade kanske 150 st, det visade sig att Access 97 (som jag använde då) "kom ihåg" kontroller som var borttagna. Alltså om jag la till 150 kontroller på ett nytt formulär, tog bort dem alla och la till 150 st, då räknade access det som om det fanns 300 kontroller.

Om du inte har så många kontroller och vill ha ut statistik-fälten på formuläret, återskapa ditt formulär i ett nytt och rent formulär så borde det gå.

/F

Har du verkligen 1000+ kontroller på ditt formulär? Råkade ut för problemet med att access klagade på att jag hade för många kontroller på mitt formulär trots att jag totalt hade kanske 150 st, det visade sig att Access 97 (som jag använde då) "kom ihåg" kontroller som var borttagna. Alltså om jag la till 150 kontroller på ett nytt formulär, tog bort dem alla och la till 150 st, då räknade access det som om det fanns 300 kontroller.

Om du inte har så många kontroller och vill ha ut statistik-fälten på formuläret, återskapa ditt formulär i ett nytt och rent formulär så borde det gå.

/F

Hej Fredrik och tack för inlägget!
Jag har 235 fält definierade i datakällan för formuläret och om jag där definierar in fler fält så får jag felmeddelandet.

Det kan mycket väl vara som du säger att den "kommer ihåg" gamla borttagna fält.

Hur återskapar man sitt formulär i ett nytt och rent formulär utan att helt enkelt (vilket är en otroligt motbjudande tanke) göra ett nytt likadant?

mvh/ Harry

<b>Hur återskapar man sitt formulär i ett nytt och rent formulär utan att helt enkelt (vilket är en otroligt motbjudande tanke) göra ett nytt likadant?</b>

Hehe.. Motbjudande är det.. =)
Det jag kan tänka mig att man kan göra är att kopiera alla kontroller från det gamla formuläret in i det nya formuläret. Alla inställningar/kopplingar borde hänga med då, efter detta kopiera ev. vba-kod till det nya formuläret. Tänk på att labels och dylikt också räknas som kontroller, så förmodligen har du 253*2 (om du har en label för varje kontroll).

Tyvärr finns inget enkelt sätt att göra detta på och jag har ingen garanti för att det fungerar. Bara att prova sig fram..

/F

Jag är intreserad i hur Månadsuppgifter och Parameteruppgifter ser ut.

Hej igen!

Har återskapat formuläret (mha kopiering).
Resultatet var tyvärr som innan. Fältlistan tömdes (Den som visas med formuläret i designläge) samtidigt som samtliga kontroller förlorade sin kontrollkälla. Däremot så finns samtliga definieringar kvar i selectsatsen som finns i formulärets datakälla.
Vid körning fås meddelandet " FÖR MÅNGA FÄLT DEFINIERADE ".

Vid försök att plocka in ett nytt statistikfält åt gången visade det sig att när gränsen 255 fält (totala antalet alltså 235 + statistikfälten) var nådd så upphörde det att fungera. (Fältlistan tömdes).

Alltså är 255 fält en maxgräns som inte kan överskridas. (skulle ha klarat sig om jag fått in 4 fält till, men då har jag ju förstås ingen reserv för framtiden).

Du skrev 1000 som en gräns för antalet kontroller. Varifrån kommer den gränsen?
Skulle gärna vilja veta var gränsen för definierade fält finns angiven. Nån som vet?
Annars får vi väl låta frågan gå vidare till Microsoft.

mvh/ Harry

Sorry, jag hade lite fel, det var inte 1000, det var 754.

Saxat från access-hjälpen:
Number of controls and sections you can add over the lifetime of the form or report: 754



/F

Hej igen!
Tabell Månadsuppgifter innehåller 154 fält
- Månadsuppgid (räknare)
- Parameternyckel (tal)
- Månad
- Månadsuppgnr
- Anställningsnr
- Fartygs/Enhetsnr
- Befattningsnr
- Startdatum
-Slutdatum
Därefter följer löneuppgifter, olika slag av lönetillägg och avdrag osv...

Tabell Parameteruppgifter innehåller 44 fält
- Pmeternyckel (tal)
- Pmeterkategori (Skeppsbefäl,Däck,Maskin,Maskinbefäl,Kock)
Därefter följer konstanter för olika tillägg (typ timersättn.konstant för nattillägg) osv . för konstanterna finns dessutom datumfält och nykonstantvärde för att man i förväg skall kunna mata in datum f.o.m. ett nytt konstantvärde skall gälla

mvh/Harry

Mitt elementära problem innehåller tydligen många bottnar.

Har just upptäckt (fått reda på) att en tabell har en begränsning på 255 fält.
Det visar sig även (vid granskning av Access- specifikationerna) att en fråga har en maxgräns på 255 fält.
Min datasource för mitt formulär innehåller en Select-sats med ett antal fält. Det är det antalet fält som jag nu försöker utöka till ett antal större än 255.
Verkar vara där skon klämmer.
Så nu är jag ute efter att lösa det problemet.

mvh/Harry

<b>Därefter följer löneuppgifter, olika slag av lönetillägg och avdrag</b>

Låter som något man kan bryta upp tilla rader i tabeller ocha använda det istället.
Jag är inte insatt i hur löner beräknas. Men misstänker att det är mycket komplext.
Men att lagra information som kolumner i detta fallet kanske kan lösas på annat sätt.

Jag antar att viss information kommer ha liknande karaktär.
Information med liknande karaktär kan man lagra som rader i en separat tabell och länka till posten.

Hej igen Andreas!
Jag tror att ditt förslag är det enda rätta.
Jag har för många fält i mina tabeller och kommer säkert att även i framtiden tjäna på att dela upp tabellerna.
mvh/Harry