QuickEye

tryckte på fel knapp...

Testa import med 'Develop Settings' på 'none'. Denna inställning är på Import Photos fönstret, ner till vänster. Då importeras bilder utan LR att lägga på nån egen inställning.

//QuickEye

Hej,

Testa import med 'Develop Settings'

Hej,

Hur ser tabellen ut? ("DESCRIBE table?name" visar det).
Hur ser koden som lägger till raden ut?

//QuickEye

Hej,

Jag har använt Skype på länge men har inte sett sånt skärm... Iofs...
Pilen neråt pekar på den lilla "+" tecknet längst ner till vänster, under "telefonen".
Tycker att pilen pekar kanske mot sökfältet längst upp ('Skype Name or number') där du kan skriva in "Skype Test Call" och slå en signal dit.

//Quickeye

Det är inte kameran som tar kort - det är fotografen.
Det finns olika typer av konsertbilder som är snygga. Man kan bygga in rörelseoskarpan i kompositionen.

Var beredd på att anpassa dig efter omständigheterna.
Även världens bästa plan om superskarpa närporträtter på sångare går upp i rök om bandet lirar i motljus utan nån belysning framifrån.
Eller finns det inget dike så man får trängas med publiken: det kan vara ytterst svårt att flytta runt till en annan vinkel eller att rentav trängas så långt fram att man har "clear line of sight".
Sen är det bra att ha fotopass. Antigen söka hos skivbolaget eller höras med arrangörerna på plats. Det brukar vara första tre låtar som man får fota från diket, och oftast (99%) utan blixt. Men man lyssnar alltid på vad de säger. Det är samma vakter nästa gång också!
Det är sant att den lilla skärmen på kameran är för smickrande för bilderna: de ser inte likadant ut på en riktig skärm! Särskilt skarpan! Det löner sig att öva på hållningen: att ha bra balans, att hålla andan när man trycker av, att hålla armbågen nära kroppen. Alla smådetaljer bidrar till bättre skarpa. Det är ovanligt att ha stativ eller monopod med. Man hinner inte med det, helt enkelt. Jag brukar lyssna på låten och utforska om ljuset följer låten: då kan man fokusera i mörkret, ställa in kompositionen och man vet att vid 4:e takten i refrängen kommar trummisen att slå hårt och då går ljuset upp... Man väntar och tar en serie då.

Det löner sig att visa respekt för andra fotografer också: man hoppar inte framför en annan fotografs glugg.

Man får inte heller glömma att det finns mer att fota än bara sångaren. Kablar på scenen (om man ser de), ljus, instrument, set list: mycket. Det går att bygga in i kompositionen.

Men det allra viktigaste (tycker jag) är att "make the most of it"! Om det inte går att ta kort man tänker från början så är det att ta kort hur det går. Ha kul och om du är inte nöjd med dina bilder: det går flera tåg!

Tack, jag började experimentera lite och efter att ha fått det att funka i praktiken började jag ana hur det funkar. Det skiljer ser lite från vad jag är van vid, men det är bara att vänja mig.
Det verkar så att databasen funkar, alla manus gör vad de bör göra och slutresultatet (data som kommer ut efter all processing) är det jag är ute efter. Tack för all hjälp och tips!

Jag tror inte att det går att spänna Stealth Reporter fast på en annan rygsäck (kanske med silvertejp ).
Vad/var vill du fota?

Jag var bortrest i ett tag...

Jag måste kolla hur shellscripting och AS funkar. Iofs, FMs egen scripting funkar bra än så länge, men jag är alltid nyfiken på nya sätt att lösa problem!

I praktiken funkar min databas utan problem, men jag fortfarande fattar inte hur selfjoin på 3 poster ger bara 3 poster och inte 9... Finns det beskrivet nånstans? Tack!

Tack, Richard! Jag är inte så innte på AppleScript eller ShellScript. Vad är det bästa scripting? Eller kanske vad är för- och nakdelar av olika scripting?

Tack för alla tips!

Du har rätt, det kanske är bättre att beskriva uppgiften lite mera - my miss...
Jag har redan gjort detta i Acces några gånger, så det som är nyast för mig är att använda FM. Meningen med att kolla hur "förekommande värden" kan visas i FM var att få hjälp med ett steg i analysarbetet, inte nödvändigtvist hela uppgiften.

Hursom...
Uppgiften är att höja priserna på tusentals kunder.
Det urgamla faktureringssystemet tillåter förändringar uteslutande genom användargränsnittet, och är inte anpassad för att hantera sådana massvisa uppdateringar. Därför tankar vi ner tabellerna från detta system som jag laddar upp i FM där jag analyserar data och hanterar alla förändringar med hjälp av en manus. Jag skapar nya tabeller som vi sedan tankar upp i faktureringssystemet, och voilá - vi har nya priser!
Tyvärr är det ingen utveckling av faktureringssytemet, "bara" att ta skiten från ett system, jonglera med data på ett smart sätt i ett annat system där man kan jonglera med data, sen tanka upp det nya data i faktureringssystemet. Dvs jag styr inte hur koderna väljs, jag anpassar mig hur faktureringssystemet gör.
I faktureringssystemet väljer användare själva vilka koder de vill skapa, dvs det är inte systemet som automatiskt ger en ny kod. Detta innebär att folk väljer koder som har någon betydelse för de, och på så sättet följer koder inte varan i sträng ordning: de är huller om buller.:tveksam:

Kunder delar priser med varann, dvs två eller hur många som helst kunder ha samma priskod. Om två grupper av kunder ("höja" och "ej höja" - vi får listan av säljarna) använder samma priskod då måste vi flytta ena gruppen till en ny kod, annars antigen båda grupper eller varken av de får höjningen.
För att lösa sådana "krockar" måste man kolla vilka priskoder som krockar. Sedan skapar man nya priskoder för att ersätta priskoderna i en av grupperna. Här använder jag listan på förekommande värden.
Priskoderna är 3 karaktär långa där 0-9 och det latinska alfebetet är tillåtna. 36 karaktärer sammanlagt. Jag behandlar denna kod till som nummer i bas 36 och konverterar till ett nummer i bas 10: med nummer kan man man kan lätt sortera och räkna fram skillnaden mellan olika koder. Här använder jag Middle() och tack för tippsen om Let() - jag skrev ut hela listan på alla 36 karaktärer.:">
Iom nästa lediga nummret är inte nödvändigt är det sista +1, så letar manuset igenom listan på förekommande värden och väljer en "lucka" där skillnaden mellan koder som följer varann enligt sorteringen är högre än 1. Den nya koden i bas 10 räknas om till ett nummer i bas 36 och las till till listan på förekommande värden. Fram till nästa priskod som krockar och börja om...

Det blir en likadan manus till för att även olika priskoder använder samma prisberäkningar, och där kan krockar förekomma också. Som tur är så det är likadana koder.

I Acces körde jag med SELECT DISTINCT. I FM ger jag varje rad inom tabellen som innehåller kundnr och priskod (det finns ingen tabell bara på priskoderna iom faktureringssytemet är inte relational databas) ett löpnummer. Self join och If() ger mig en flag ("Unique") som identifierara en enda förekomst av varje priskod. Find på denna flag visar en lista på alla förekommande värden, utan upprepningar.
Det som jag frågade om var hur FM funkar gentemot Acces när det gäller länkar. Som jag skrev, jag skulle förvänta mig att 9 värden i mitt exempel (se exemplet med 3 stycker aaa i min tidigare inlägg). Och 3 av de 9 har den där flag, dvs bör visas om jag kör find på "Unique". Men jag får ett enda värde som får flag, som är precis vad jag är ute efter, men då är jag förvirrad om hur join väljer vilka värden som matchas. Hur funkar detta i FM egentligen?

Tack!

Unika värden behöver jag för att räkna fram ett nytt värde som förekommer inte. Uppgiften är ungefär så här:
Två kunder använder samma priskod. Vi måste höja priset på ena kunden, men inte på den andre. Iom att de använder samma priskod kan jag inte höja priset bara så där då båda kunder får höjningen. Så jag måste flytta ena kunden till en helt ny priskod. För att få fram en ny kod så måste jag kolla vilka som används redan. Här används listan på förekommande värden (detta begrepp verkar vara bättre).
I detta uppgift spelar det ingen roll hur många gånger ett värde används, bara att det förekommer.

Kanon, tack så mycket! Jag testar olika metoder själv under tiden, men det säkert finns mängder av finesser som jag har ingen aning om - än!

Just nu är det lite rappare på att räkna fram Sum() från en selfjoin, men det fortfarande är långsamt att köra find på ett värde inom detta Sum fält.

Det är lungt, jag skriver lite flummigt själv...

Visa endast uteslutna på sökning på ! ger bara B och C i ditt exempel, och inte tre poster:A, B och C. Och det är vad jag är ute efter, och det är vad SELECT DISTINCT ger.
För mig är "listan på unika värden" är en lista på alla värden som förekommer i ett fält. Bara en enda av förekomster på en dubblett visas. Jag verkar använda begreppet "unikt värde" på lite annatt sätt...

... och med selfjoin och serienr trixet får jag 1 på en enda förekomst av varje värde, så om jag filtrerar på detta fält så får jag en lista på en enda förekomst av alla värden

Jag är med på !. Testade och kom fram till samma som du skrev. Jag kollade vilka värden förekommer bara 1 gång och de var inte med när jag sökte på !.
Sökning på ! är bra att kunna, men ger mig inte vad jag var ute i just detta sammanhang. Jag ville kolla om det är likadant som SELECT DISTINCT i Access SQL, men det är inte.

Jag behöver en lista på alla värden som förekommer, men listan behöver att innehålla varje värde 1 enda gång, även om det förekommer flera gånger i tabellen. (Det är vad SELECT DISTINCT gör.)
Nu har jag en lösning som funkar i praktiken, men går emot hur min hjärna uppfattar länkarna efter att ha jobbat mycket i Acces. Och 3x3 aaa handlar om detta, inte om "!" längre.

Allt detta blev viktigt för att alla länkar som jag har gör att databasen blev jättelångsam, trots att den är inte så himla invecklad. Nu försöker jag att "streamlinea" och kolla på olika likvärdiga sätt att få fram det jag är ute efter.:cool:

Tack!