Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

Göra fält icke-modierfierbara men...

Tråden skapades och har fått 4 svar. Det senaste inlägget skrevs .
1

Vi har ett gigantiskt Filemakersystem som ska läggas ned här så småningom, och jag håller på att kolla upp olika lösningar på hur jag ska omvandla det till en tittkopia. Användarna ska alltså kunna logga in och kolla gammal data, men inte modifiera några fält. Det enda dom ska kunna göra är söka och titta.

Jag vill nu ha tips på det absolut smidigaste sättet att lösa det på.

Bakgrundfakta:
* Ett konstant toppliggande register (med ungefär 60 layouter) visar all data från 36 olika bakgrundsregister genom portaler och fält med direkta relationer.
Filemaker 6.0v4 används på klientsidan, och Filemaker 5.5 Server används på en Linuxserver.

Några fält är det naturligtvis väldigt enkelt att fixa bara genom att högerklicka och ta bort bort markeringen i kryssrutan "Allow entry into field". Men kan inte göra det på relativt många eftersom om man gör så så kan man inte få fram scrolllistan på de fälten. Och jag kan inte GUImässigt tillåta att dra ut de fälten så att allt visas hela tiden. Jag måste alltså spärra fält, utan att scroll-listan försvinner.

Någon som har en god tanke?

  • Medlem
  • Skellefteå
  • 2007-05-10 09:57

För de fält som du vill tillåta scrollning i men inte vill att folk ska kunna ändra kan du ju alltid skapa beräkningsfält. Lite bökigt - men funkar.

Typ:
FältSomBehöverScrollist Text
bFältSomBehöverScrollist Beräkning (text) =FältSomBehöverScrollist

Kendok har rätt, även om jag inte håller med om döpningen av fältet, jag ser hellre att beräkningsfältet heter Fältsombehöverscrollist_C (C för calculation). Fördelen är att när man sorterar fältnamnen i bokstavsordning och skall byta fältet i layouten (gnm att dubbelklicka på det) så hamnar de två fälten exakt intill varandra med det namnet.

Sedan ser jag förstås ingen anledning att lägga ner ett FM-system, någonsin, kanske ni har haft dåliga konsulter som gett er dåliga råd?

Ursprungligen av Taz_1999:

Kendok har rätt, även om jag inte håller med om döpningen av fältet, jag ser hellre att beräkningsfältet heter Fältsombehöverscrollist_C (C för calculation). Fördelen är att när man sorterar fältnamnen i bokstavsordning och skall byta fältet i layouten (gnm att dubbelklicka på det) så hamnar de två fälten exakt intill varandra med det namnet.

Sedan ser jag förstås ingen anledning att lägga ner ett FM-system, någonsin, kanske ni har haft dåliga konsulter som gett er dåliga råd?

Nja, då beslutet att byta plattform togs fanns bara Filemaker 6. Att ha en userbase på 500 samtidiga inloggade funkade inte smidigt så att säga
Nu har detta gamla FM6 system legat kvar och använts för specifika småuppdrag, men nångång måste det pensioneras för att få ner kostnaderna (en massa servrar som kostar stålar vettu)

Tack för förslagen, men jag kom på ett annat sätt som var smidigare. Drog in en räkning av antalet tecken, ifall det var fler tecken än X så kopierades texten, så att ifall det var många så kan man klistra in all text i typ Word.
Detta går snabbare i just detta system. Hur konstigt ni än kan tycka att det låter

Angående att pensionera FM 6 systemet:
Synd, det har kommit nya möjligheter i FM 7 och 8 vad gäller att få olika system att prata med varandra med SQL via ODBC, webbpublicering mm.

Intressant problem det där, 500 samtidiga användare. En FM Server kan ju hantera 250 stycken samtidiga användare + 100 via webben + 50 JDBC/ODBC samtidigt, totalt 400.

Jag kan tänka mig flera metoder att lösa det här problemet genom att komplettera maskinparken med en MySQL-maskin med webbserver och en utvecklingsmiljö på som tex Lasso och flytta omkring saker mellan MySQL, Webbpublicering och FileMaker självt med lite påfallande enkla synkroniseringsrutiner (vilka kan skrivas i flera olika språk Lasso eller SQL tex), en plugin eller två och en hel del programmering och utveckling. Vore väldans kul att prova bygga något för 500 personer.

Fördelen med att ha kvar FM i en sådan här situation brukar vara användargränssnittet som man kan göra mera mera effektivt och oftast lägre utvecklingskostnader än alternativen.

1
Bevaka tråden