Hej David,

Vad är du ute efter för funktioner?

/Robert

Jag har ingen erfarenhet av dessa men kommer att ge mig på att titta närmare på dem.
Vi får dela med oss av vår erfarenhet här.

/Robert

Så fick jag äntligen tid att testa...

Och resultatet blev att det inte spelar någon roll vilket plugin man använder, åtminstone inte för det jag försöker göra. Har än så länge bara testat på Mac.

Det statement jag testar med är:
SELECT t.ISBN FROM zTITLE t join   zPUBLISHER p on p.VendorCode = t.VendorCode WHERE lower(t.Title) LIKE '%book%' OR lower(t.Author) LIKE '%book%' OR t.ISBN LIKE '%book%'  ORDER BY p.Sort ASC, t.Title ASC
Jag kör detta mot 30340 poster i Title och 42 i Publisher.

Och alla plugin är lika snabba - 6 sekunder för DoSQL och 24U Toolbox och 7 för de övriga, men den skillnaden är nog bara en fråga om avrundning.

De plugin jag testat är:
2empowerFM_SQL_Runner 2.33
Mitt egna custom plugin skapat med 360Works ScriptMaster Advanced 4.124
MBS 2.3r1
MMQuery   MMQuery v.1.2.0
myFMbutler_DoSQL 01040401
24U Toolbox 1.1.1

Mitt val faller mycket enkelt på det med 360Works ScriptMaster Advanced 4.124 skapade pluginet, eftersom jag redan använder det i denna lösning.

Det finns andra skillnader mellan plugin-programmen, bl.a. för att göra det "enklare" att hantera diverse aspekter, men eftersom jag bara är intresserad av att köra ett SQL statement rakt av behöver jag inte alla de finnesser som finns i synnerhet i MMQuery.

Virtual list är helt klart ett bra fall för SQL; jag använder också SQL till detta i den lösning jag jobbar på. Dessutom använder jag det till en sorts importförfarande, för att skapa ett stort antal poster utifrån en pipe-avgränsad textfil - också där med betydande tidsvinst.

Kort uppdatering då detta ämne kan vara av aktualitet.

Jag har precis avslutat första versionen av en re-write av en existerade lösning från ren FileMaker med relationer sorterade på icke-indexerbara beräknade fält till en ExecuteSQL-baserad modell där jag hämtar en sorterad array av id-värden. Pga det mycket specifika gränssnittet var dessa de två bästa/minst dåliga alternativen.

Än så länge ser resultatet mycket lyckat ut, även om jag för vissa fall har 4-5 JOIN och en del rätt komplicerade SELECT (ex.vis en radda dubbla LIKE med wildcards). Mycket snabbare och inga konstiga, halvt spontana "omsorteringar" när i relation/sorteringsordning använda fält ändras.
Ett trick som fick det att fungera riktigt bra var att jag övergav "klassisk" virtual list där man arbetar med icke-lagrade beräkningar som hämtar värden från array för en loop som sätter fältvärden för ett indexerat fält för det antal relaterade poster man kan se på skärmen (allt efter skärmstorlek - 65 poster på min iMac 27").

En annan sak jag är rätt nöjd med är ett sätt att sortera poster med "vanlig" FileMaker sortering och vara säker på att få exakt samma sorteringsordning. Istället för att försöka programmera ett otal kombinationer av sortering på indexerade fält på ett sätt som följer sorteringsordningen i min Id-array, kom jag på att, eftersom mina Id-värden alltid är 13 tecken långa (ISBN), kan jag helt enkelt använda ett icke-lagrat beräkningsfält med . Denna enkla formel utvärderas riktigt snabbt i synnerhet i de "vanliga" fallen där man har upp till några hundra eller  högst ett par tusen värden i $$ISBN_array.