Triplee23

Jeg betvivlar inte din kunskap om FM så jag kommer bygga om min relation enligt din rekommendation.

I mitt försök på att förstå detta försöker jag här beskriva det jag uppfattar att du säger, hoppas jag har uppfattat rätt:

1. Layouts bör alltid bygga på grundtabellen, aldrig tabellförekomster? När du skriver att det är skillnad mellan en relation beroende av om man tittar åt vänster eller åt höger. Kan du förklara detta igen, vet inte om jag förstår skillnaden?

2. Du säger att tabellförekomster (kopior på grundtabellen) alltid visar samma antal poster och att något urval aldrig sker. Det förstår jag nu, är det samma vid relationer mellan olika grundtabeller?

3. Även om det kanske kan framstå som det, jag har inte jobbat mycket med SQL. Ordet Selv-join kommer från VTC.com och deras omfattande Filemaker tutorial.

Jag skrev inledningsvis att jag inte önskade portals för just denna layout. Jag är inte i princip emot portals, jag tycker dock att de är lite begränande vad gäller grafiska möjligheter. Portals är i mitt tycke en tabell och begränsas av layoutens bredd. Jag önskade mer "formulärkänslan" där man fyller i saker på olika ställen på en sida för VARJE post i tabellen. Har jag rätt i min syn på begränsningarna i portals eller finns det andra sätt att använda portals tycker du?

Jag är nyfiken på det du skrev om script triggers. Kan man få script att köra automatisk vid musklick på en av FMs standardtabbar?

Väldigt tacksam

Som svar på en fråga från ditt första svar. Jag har FM 10 så det borde gå med script triggers.

Lite info: Jag har två layouts, en MEDLEMMAR och en MEDLEMMAR_AKTIVA. I detta fall står jag i MEDLEMMAR_AKTIVA.

1. Jag har nu fått scriptet att fungera, jag hade tittat på fel tabellförekomst. Eftersom jag står i MEDLEMMAR_AKTIVA behövde jag hämta relaterade poster från MEDLEMMAR. Det ser ut så:

If [MEDLEMMAR_AKTIVA::xstatus="Aktiv"]
Go to Related Records [Show only related records; Match found set; From table: "MEDLEMMAR_AKTIVA"; Using layout: "Aktiva Medlemmar" (MEDLEMMAR_AKTIV)]
End If

2. Jag står i tabellförekomsten MEDLEMMAR_AKTIVA.

3. Jag vet inte var jag har skrivit att det finns en relation xstatus till xstatus. Jag har enbart en relation mellan xstatus och status.

4. Värdena är rätt, det kan ha slingat in ett stavfel i foruminlägget.

5. Datatypen är text i båda fälten, både xstatus och status.

6. MEDLEMMAR_AKTIVA

Jag kan absolut lägga in skärmdumpar, ska göra det nästa gång.

Sedan en fråga kring detta med relationer. Jag har lärt mig något viktig här och det är att relationen bygger på där jag står, alltså den tabellförekomst som layouten använder. Det jag dock inte förstår är värför jag behöver scriptet. Jag önskar ju här bygga en layout på MEDLEMMAR_AKTIVA, en tabellförekomst som väl redan har sorterat ut poster med status = aktiv. Har den inte det? jag trodde relationen i sig gjorde gallringen eftersom jag har lagt in ett urvalskriterie i relationen, nämligen den att xstatus = status (xstatus = aktiv). Borde inte detta gallra bort alla med status=inaktiva? Kan du förklara detta?

Tack för utomordentlig förklaring. Anledningen till att jag nog väljer ord som join och vyer är att jag sitter med engelsk version av FM och gissar ibland lite kring vad det eventuellt heter på svenska. Jag kommer i forsättningen använda de engelska termerna.

Jag har nu gjort enligt din förklaring med får det tyvärr inte att fungera. Jag undrar på om mitt script är korrekt.

Jag har nu två table occurances, MEDLEMMAR och MEDLEMMAR_AKTIVA (jag har inte gjort någon för inaktiva än). Dessa har en relation via fälten xstatus <<-->> status. xstatus är ett globlat beräkningsfält med värdet "Aktiv" och status är ett textfält där input via radioknapp (Aktiv/Inaktiv). I layouten finns en knapp med följande script:

If [GetField ( MEDLEMMAR_AKTIVA::xstatus ) = "Aktiv"]
Go to Related Record [Show only related records; From table: "MEDLEMMAR_AKTIVA"; Using layout: "Aktiva medlemmar" (MEDLEMMAR_AKTIVA)]
End If

Efter att ha tryckt på knappen visas forfaranda alla records i layouten (både status = aktiva och inaktiva). Jag har försökt ha xstatus på båda sidorna i relationen utan att det spelar någon roll.

Vore tacksam om jag kunde få ytterligare hjälp.

Hej,

Har suttit länge med ett problem jag inte hittar lösningen på. Jag har en medlemsdatabas som består av både aktiva samt inaktiva medlemmar. Jag vill gärna skapa två vyer, en med samtliga medlemmar och en med bara aktiva medlemmar. Jag har skapat en field som heter status (radioknapp, text; aktiv/inaktiv) och en field xstatus (global; innehåller värdet "aktiv"). Jag har sedan gjort en self-join status=xstatus via tabellerna MEDLEMMAR och MEDLEMMAR_AKTIVA och hoppades att min vy baserad på MEDLEMMAR_AKTIVA skulle visa mig enbart medlemmar med status=aktiv. Oavsett hur jag gör klarar inte relationen att ta bort inaktiva medlemmar i min vy baserad på MEDLEMMAR_AKTIVVA (och därmed visas allt i båda vyerna). Är det inte möjligt det jag försöker göra? Jag ser gärna att detta kan lösas utan portal då jag vill bläddra via formulär (FORM).

Tack för svar.
Triplee23

Hej,

Jag är rätt ny i att använda FM och har lite svårt att förstå skillnaden mellan Calculation Field och Auto-enter Calculation. För mig verkar det nästan vara samma sak. När ska man använda den ena kontra den andra. Den enda skillnaden jag kan se är att man i Auto-enter Calculation kan förhindra att en man skriver över redan genomförd beräkning. Är detta enda skillnaden?

Tack för svar!

Jag köper absolut dina argument eftersom jag utgår ifrån att du kan FM mycket bättre än vad jag kan. Tror jag har har hittat en lösning enligt din strategi. Återkommer säkert med flera frågor ...

Tack för din input, det kan absolut vara så att jag komplicerar och det önskar jag inte. Ser dock inte hur kan kan koppla allt i samma PRODUKTREGISTER eller PRODUKTER som jag har valt att kalla det.

I min PRODUKTER har jag det som du föreslår:

produkt_id
produkt_pris (i kroner)
produkt_enhet (i t.ex. kwh)
produkt_beskrivning (text)

Det är bara det att varje medlem har olika antal av varje produkt, vilket jag lagrar i ELAVLÄSNING och BÅTPLATS

ELAVLÄSNINNG

avläsning_id
medlems_id
senaste_avläsning (kwh)
förra_avläsning (kwh)
datum_avläsning (datum)

BÅTPLATS

båtplats_id
medlems_id
båtplatstyp_1 (boolean)
båtplatstyp_2 (boolean)
båtplatstyp_3 (boolean)
båtplatstyp_x (boolean)

Detta ger en tabell som kan se ut:

båtplats_id - medlems_id - båtplatstyp_1 - båtplatstyp_2 - båtplatstyp_3
1 - 3 - 0 - 1 - 0
2 - 5 - 1 - 0 - 1

för samtliga 270 medlemmar....

Jag ska altså skapa en faktura (med ORDERRADER) som hämtar produktinfo och produktpris från PRODUKTER för att sedan hämta antalet (quantity) från antingen ELAVLÄSNING eller BÅTPLATSER. Enligt ditt förslag behöver jag ett produktregister som även anger antal (quantity) per medlem vilket inte vara så klokt.

En annan fundering är att jag inbland vill ha en elfaktura, ibland medlemsavgift. Detta innebär en relation till både BÅTPLATS och ELAVLÄSNING, dock inte samtidigt. Går det att göra en relation som på något sätt är variabel?

Jag kanske inte behöver någon relation alls, jah kan hantera allt i ett script? Går det att använda data mellan tabeller utan att det är en relation mellan, sköta allt i scriptet?

Synpunkter eller input?

Hej,

Jag försöker bygga ett enkelt fakturasystem för en båtklubb men det har visat sig svårare än vad jag hade tänkt mig.

Bakgrund:

Båtklubben har olika båtplatser men olik pris. Faktura för medlemsavgift skickas ut två gånger per år. En medlem kan ha flera båtplatser.
Varje båtplats har ett eluttag med mätare. Faktura för elförbrukning skickas ut en gång per kvartal.

Jag har lagt upp följande tabeller:

MELDEMSREGISTER
BÅTPLATER (anger medlem och antal av varje båtplatstyp)

medlems_id
båtplatstyp_1
båtplatstyp_2
båtplatstyp_3

PRODUKTER (priserna för de olika båtplatstyperna och kostnad kWh el)
ELAVLÄSNING (innehåller senaste elmätning för varje medlem)
FAKTURAREGISTER
ORDERRADER

Jag har fram tills nu följande relationer:

MEDLEMSREGISTER ----> medlems_id <------- FAKTURAREGISTER
FAKTURAREGISTER -----> faktura_id <------- ORDERRADER
MEDLEMSREGISTER ----> medlems_id <------- BÅTPLATSER
ORDERRADER ----> produkt_id <---------- PRODUKTER

Nu undrar jag vilka andra relationer jag behöver. Jag vill att en ny faktura skapas när jag lägger in en senaste elförbrukningen i ELAVLÄSNING. Jag önskar givetvis att inrapporteringen av elförbrukningen automatisk ska skapa en faktura med tillhörande orderrad (1 st)

Jag har funderat på att göra detta med ett script, ett script som aktiveras via en knapp. Måste jag ha relationer för att få ett script att fungera? Jag ser framför mig ett script som skapar en faktura i FAKTURAREGISTER samt en rad i ORDERRADER med information från ELAVLÄSNING, dock undrar jag om en relation är en förutsättning för att detta ska fungera?

Jag önskar också en lösning där jag skapar samtliga fakturor avseende medlemsavgift automatisk med hjälp av en knapp (script). Hur ska relationen mellan FAKTURAREGISTER och ORDERRADER se ut mot BÅTPLATSER för att uppnå detta. Lite samma frågeställning som ovan.

Kan jag lösa detta på annat sätt? Mest nyfiken på hur realtionerna bör se ut och hur detta kan lösas på enklaste sätt.

Det jag upplever skiljer detta från traditionella fakturasystem är att antalet produktenheter (typ av båtplats eller elförbrukning) är givet för varje kund och finns redan registrerad i olika tabeller (BÅTPLATSER, ELAVLÄSNING). Antal kWh eller antal båtplatser är inte något man väljer för varje gång man lägger till en orderrad i fakturan. Detta ska "hämtas" från respektive tabell.

Hoppas jag har lyckats förklara problemställning på ett förståligt sätt.

Jag arbetar i FM 9.

Tack för all hjälp!

Jag är rätt ny i FM så detta var bra hjälp. Förstår jag dig rätt, rent generellt i att:

Om jag sorterar en tabell utifrån vissa kriterier så vill en relation alltid returnera den överersta recorden (raden) i tabellen?

Kopplat till ditt exempel så vill:

consumption = reading_value - äldre_registreringar::reading_value

returnera den övre raden i [äldre_registreringar] eftersom vi inte specifserar en specifik record.

Har jag förstått rätt?

Vilken funktionen har andra relationen du föreslår:

_kp_reading_id > _kp_reading_id

Kan du förklara syftet med den. Relationen mot [äldre_registreringar är ju enbart intressant vi inmatning av en ny registrering eftersom jag då vill räkna ut en differens. Då vill _kp_reading_value alltid vara större än samtliga äldre_registreringar::_kp_reading_id så jag kan inte se att denna har något syfte. Är det något jag inte förstår?

Info: jag kör FM 8.5 Adv

Behöver hjälp med att hitta värdet i en tidigare record i en tabell. Jag har en tabell där jag registrerar medlemmars enegiförbrukning (mätarställning). Tabellen ser ut så här:

_kp_reading_id
_kf_member_id
reading_value
previous_reading_value
consumption = reading_value - previous_reading_value

I previous_reading behöver man altså hitta en tidigare record i samma tabell för just detta medlem. Anledningen till detta är att jag behöver veta differansen för att se förbrukningen sedan senaste avläsning. Går detta att göra via en calculation? Jag måste bara precisera, om detta inte redan framgår, att värdet som jag vill lägga in i previous_reading kan ligga var som helst i tabellen. Jag kanske behöver lägga till ytterligare en tabell som ständigt har senaste avläsning?

Tack för svar, jag kommer att läsa på för att sedan prova enligt dina instruktioner. Kommer säkert ställa frågor igen om jag inte lyckas.

Hej,

Är rätt ny i FM men har gjort några tabeller i en fil för att skapa ett fakturasystem. Har en tabell med kundinformation (medlems_id, namn etc.) en tabell med fakturainformation (faktura_id, medlems_id, datum etc.) och en tabell med orderrader (faktura_id, beskrivning, pris, antal). En faktura vill givetvis ha en koppling till flera orderrader. Kan någon hjälpa mig förstå hur jag kan få upp en "form" med en faktura och samtliga orderrader kopplade till denna faktura?

Varför inte använda apf/netatalk istället. Mina Ubuntudiskar kommer automatisk upp i finder som om de vore en vilken som helst nätverksdisk. Jag har ext3 på min Ubuntubox.

Samma status på min beställning. Ringde TNT och enligt dem så ska leverans ske imorgon. Får hoppas de är att lita på.

Beställningsstatus för min Family Pack har precis ändrats till:

Shipped on: Oct 24, 2007 via TNT Nederland B.V.

Tyvärr visar leveransstatus fortfarande leverans 30 oktober. Märkligt att det ska ta så många dagar från Holland. Hoppas den kommer tidigare.