Conversie van Filemaker 6 naar 7 : reacties gevraagd.

[Rony Rabijns]

Open discussie : Conversie van 6 naar 7

 

Wij werken al jaren met Filemaker Pro. Tientallen applicaties, klein en groot, zijn gebouwd, opgeleverd en in gebruik. Vele versies hebben we overleefd. Naadloos zijn we telkenmale overgeschakeld naar hogere versies, van niet-relationeel (subrecords o.b.v. herhalende velden) naar relationeel (portals en conditional valuelists). Allemaal zonder problemen en te overzien qua tijdsbestek.

 

Anno 2005 klinkt dit verhaal plots heel anders. Het wordt wat negatiever.

 

Ik stel vast dat veel van onze klanten én klanten van andere developers, blijven werken met de versie 5/6 van Filemaker. Dit tegen beter weten in, het risico lopend om binnen afzienbare tijd keihard met hun gezicht tegen de muur te lopen.

 

Waarom dan wel ?

Wel, je kan sowieso geen 5/6 licenties meer aankopen, dus netwerkuitbreidingen bij de klant zijn niet meer opportuun; de hardware verandert vandaag de dag zo snel dat je bij de aankoop van een nieuwe PC het risico loopt dat Filemaker 5/6 niet meer ondersteund wordt.

Genoeg redenen om je klant te doen nadenken over een migratie naar FM 7.

 

Maar ... Migratie kost tijd.

 

Betaalt de klant dat ? Wellicht niet voor de volle 100%.

Hoeveel tijd ? Dat hangt af van de lijken die uit de kast vallen. Waarschijnlijk heb je die applicatie jarenlang uitgebreid met van alles en nog wat, vaak zonder goed te documenteren waarom en hoe.

 

Maar ... Hoe ga je migreren ?

 

Oh simpel toch ! We nemen de FM 6 files, openen die in FM 7 en alles gaat volautomatisch. Klopt !

 

Maar ... Gaat alles dan nog goed na conversie ?

Nee, meer dan waarschijnlijk niet.

Uit ervaring blijkt dat de nieuwe structuur van FM 7 je verplicht om alles grondig na te kijken. Sinds FM 7 is het commit'en van records veranderd, is er een context bijgekomen, kijken we totaal anders naar relaties, zijn sommige scriptstappen en functies verandert/verdwenen, kunnen we meerdere vensters openen, ...

 

Stel dat je toch allemaal opgelost krijgt. Zijn we er dan ?

Nee, want we zitten nog steeds met een multi-file oplossing en om een aantal redenen is het wellicht beter de oplossing single-file te maken.

 

Dat kan Filemaker 7 dan toch wel voor je doen ? Nougabollen !

Ook de developer-versie kan dat niet.

 

Op naar de third-party leveranciers ...

 

New Millenium communications heeft een aantal tools ontwikkeld die bestemd zijn het conversie-proces te begeleiden : FM Robot, Conversion Log Analyzer, MetaDataMagic, ....

Die dingen werken en doen wat ze schrijven dat ze moeten doen, maar ze doen - en let nu goed op - ze doen vooral GEEN conversie. Ze doen in hoofdzaak "post-conversion"-dingen. Controle vooraf dus.

 

En FM Robot dan ... ? Daar vertelt iedereen toch heroische verhalen over ... Niet dan ?

Ja en nee.

Je kan bijvoorbeeld wel met FM Robot je single files samenvoegen tot één bestand. Maar dan begint de ellende pas ....

 

Je hebt geen enkele relatie meer die er vroeger lag tussen je single-files. Je hebt geen enkele relatie meer die er vroeger was in het (geimporteerde) bestand zelf. Omdat je geen relaties hebt, werken de lookups, calculaties enz ook niet meer na import door FM Robot. Je hebt geen scripts. Die zal je allemaal manueel moeten importeren uit iedere single file. Omdat je geen relaties hebt, staan je scripts vol fouten. Omdat context nu belangrijk is, moet je ieder script opnieuw testen om te zien of het nog doet wat het moet doen. Maar .... je hebt ook geen layouts ! Oh maar die kan je toch kopieren en plakken ? Ja hola ! EN de buttons dan die er aan hingen ? En de valuelists die aan de velden hingen, en ......

 

Ik kan zo nog wel een tijdje doorgaan, maar ik neem aan dat bovenstaand verhaal meer dan genoeg zegt over de schrijnende tekortkoming in FM 7 : de mogelijkheid om vanuit een Database Design Report een complete oplossing (meerdere originele 6-bestanden, plus 50 bvb) integraal in een keer te importeren, zodanig dat de koppelingen wel allemaal bekend zijn ...

 

Daarom ....

 

Tot op heden heb ik bij mijn klanten de oplossingen die operationeel waren, van scratch gebouwd. Dat was te doen, omdat je begint met de kleinste applicaties. Tenslotte heb je ook een leerproces door te gaan, en dat doe je niet bij je meest complexe applicatie. Het voordeel van deze manier van werken was, dat je op het einde van de rit een oplossing hebt, die in 7 werkt, maar ook op zijn "zevens" gemaakt is.

 

Als je kiest voor de conversie van multi-files naar multi-files, heb je weliswaar alles in 7 draaien, maar gebouwd op zijn "zes". Niet goed dus.

 

Conclusie :

De applicaties die nu nog liggen te wachten op conversie, kunnen niet van scratch gebouwd worden. O.a. wegens veel te duur, te tijdrovend, kortom niet te overzien.

 

Conversie naar een multifile-7-structuur is geen optie wegens te langzaam in gebruik, en rekening houdend met de toekomst (privileges e.d.), moet de oplossing zoveel mogelijk in 1 bestand terechtkomen.

 

Vandaar ...

 

Ik ben er rotsvast van overtuigd dat ik dus niet de enige ben met dit probleem. Daarom zou ik dit topic willen starten om reacties te verzamelen van andere developers die conversies achter de rug hebben. Bij voorkeur zij die van multifile naar singlefile gegaan zijn.

 

Welke tools gebruik je ?

Waar zaten de problemen ?

Welke methode gebruik je ?

 

Ik heb al vanalles getest, maar er is niet één goede methode.

Ik hoop hier met open vizier jullie ervaringen te kunnen lezen.

[AvD]

Hartelijk dank dat je de zaken zo scherp en duidelijk stelt.

Onze ervaringen kort samengevat: de meerkost verbonden aan de migratie is ENORM. Heel weinig klanten zijn bereid die te betalen, zeker niet omdat de grootste voordelen van de zeven aan developerszijde liggen. Je zou het als een service kunnen beschouwen de migratie dan maar voor een groot deel zelf te bekostigen. Maar we hebben het hier uitgerekend. Het aantal manuren dat daaraan besteed moet worden is - voor de totaliteit van de klanten met complexe solutions - ontzagwekkend groot. Welke developer kan zo lang werken zonder dat dat aan de klant doorgerekend wordt?

(wordt vervolgd)

[RON7]

Prima opgesteld van Rony,het lijkt een interessant discussie punt te worden.Ik had 7 bijna een jaar in de kast liggen om deze redenen.Voor een simpele oplossing no problem,maar moet nu enkele complexe toepassingen updaten...en inderdaad enkel te doen van scratch...gevolg per oplossing enkele maandjes bezigheid.Heb nu wel ervaren dat als je in 7 een Databank picobello standaard opmaakt met de steeds terugkomende gegevens zoals klanten , produkten , groepen , leveranciers etc. er al veel uren gewonnen worden naar de andere oplossingen toe.Maar dan moet de gebruiker natuurlijk tevreden zijn met eventueel nieuwe layouts (kan ook een aanwinst zijn)

Ik gebruik CNS menu voor de databank met menudata in de plugin,zo zijn de menus voor een andere oplossing in no time aangepast.Voor de overige multifiles: eerst de multifile conversie en dan bouw ik alles verder op in de standaard databank.(soms met en soms zonder vloeken )

Als besluit,ik vind het de moeite om 7 te gebruiken en raad ook een update aan ondanks de nodige werkuren Voor een klant is het trouwens ook veel interessanter naar de toekomst toe,zijn bedrijf zal immers ook niet stil (mogen) blijven staan.

@ AVD Misschien zijn klanten wel geneigd te updaten mits een gespreide bijdrage over bvb 1 of 2 jaar die nu kan ingaan.Zodoende kan jou bedrijf rustig updaten en telkens een klant zijn nieuwe versie aanbieden.

Jullie worden betaald voor je werk en een maandelijks bedrag schrikt een klant niet zo af.

Plus een pakket produkt van sommige big boys kost zowiezo een kapitaal aan onderhoudscontracten,en laat ze dan aub niet even langs komen voor een aanpassing of herstelling want dan ben je in no time het maandoon van een werknemer kwijt

[AvD]

Dank aan Ron7 voor zijn antwoord. Het zou nog interessanter geweest zijn indien we wisten van wie het kwam (wie is Ron7?) en waarop de bewering steunt dat de klanten dat wel allemaal zullen betalen. FileMaker heeft zelf documenten verspreid waarin de migratie-kost geschat wordt op een bepaald percentage van de oorspronkelijke development-kost. Welnu, de gemiddelde KMO is NIET bereid dat bedrag op te hoesten. Kamagurka maakte ooit een cartoon met daarop de uitgever van een krant en zijn hoofdredacteur. Zegt die hoofdredacteur: "Goed nieuws, patron, onze lezers zijn alweer dommer geworden.". Waarop de uitgever: "Uitstekend. Zet dat maar op de frontpagina". Welnu, wij hebben zo geen lezers... Jij wel, Ron7?

[RON7]

Dank Avd,heb mijn profiel speciaal voor jou een beetje aangepast

Ik ken de gemiddelde Belgische KMO goed genoeg om te weten dat ze zowiezo niet graag geld uitbesteden aan software.

Dit is gewoonweg een feit,misschien zou er al veel meer interesse zijn in 7 indien ze keygens ,cracks hadden enz... en dan nog ! (Fm is niet gratis!)

Mijn punt is dat een beetje intelligente zaakvoerder weet dat een goed geautomatiseerd en overzichtelijk bedrijf hem hopen erger en onnodige kosten kan besparen.Dit is dan geen domme lezer Avd maar een slimme;en die kan je een nuttig produkt wel verkopen ALS hij er voordeel mee doet.

Het wordt bovendien hoog tijd dat de gemiddelde Belgische KMO wat doet aan automatisatie en bedrijfsbeheer.Zou misschien wel goed zijn om het falingcijfer wat naar beneden te halen.

En ik wil me zeker niet met jou bedrijf moeien maar deed een suggestie dat de klanten misschien wel willen updaten mits gespreide betalingen over een periode,tijdens die periode kan een update trouwens zonder deadlines en stress worden uitgevoerd.

Het lijkt me dus (careful maybe)belangrijk om de slimme klanten een voorstel of mailing te zenden met uitleg over de voordelen van een update en eventuele nieuwe mogelijkheden in zijn huidige oplossing.

En ik denk dat die er met 7 zeker zullen zijn

 

Mvg Ron

[AvD]

Mijn punt is dat een beetje intelligente zaakvoerder weet dat een goed geautomatiseerd en overzichtelijk bedrijf hem hopen erger en onnodige kosten kan besparen.

Dit verrast me nu toch wel! Die zaakvoerder waar jij het hier over hebt, die hééft al zo'n geautomatiseerd bedrijf, die weet al tien jaar lang dat dat hem veel geld bespaart, en die heeft daar zeer flink in geïnvesteerd. Probleem is dat hij nu ongeveer de helft van dat bedrag opnieuw moet ophoesten. En waarvoor? Voor een upgrade waar vooral de developer beter van wordt... Tenminste... tenminste als de klant zo'n upgrade zou willen, EN DAT BLIJKT NU NET NIET HET GEVAL TE ZIJN. Bij alle collega's die we offside al gesproken hebben, horen we dezelfde reactie. Het is kenmerkend in dit opzicht dat van alle grote development-bedrijven geen enkel een complex systeem heeft gemigreerd.

[JeanWM]

Als buitenstaan(lan)der heb ik het voordeel dat FileMaker hier niet zo bekend is.

Ik kan dus zonder meer alles in FM 7 aanbieden, en de weinigen die hier een FileMaker toepassing hebben, hebben er eentje in FileMaker 4...misschien zelfs 5.

En om het geheel rond te maken, ik heb nog steeds een (zeer trouwe) klant in Belgie die mijn toepassing heeft draaien in FM 4 onder Win 3.11....nogal wiedes dat die zeker niet naar de 7 gaat overstappen....

 

Ik kan me echter goed inbeelden dat een bedrijfsleider wat negatief reageert.

 

Indien je alle mogelijke voordelen van 7 opsomt om hem te overtuigen, zeg je tegelijkertijd dat de vorige versie (lees toepassing) in feite niet zo goed was.

Het ware volgens mij beter geweest indien de 6 nog een tijdje was blijven voortbestaan in plaats van die lijn definitief en op zo’n korte termijn door te snijden.

Of dat er andere/betere tools waren om de conversie te maken (zoals we trouwens gewend waren) inplaats van een radicale migratie.

 

Ik denk dat vele gebruikers dan die kost (conversie) gemakkelijker zouden aanvaarden, die zou trouwens zowiezo al lager zijn...

Het vertrouwde zou langer ‘voelbaar’ blijven. Ten slotte hebben we jaren zonder al te veel problemen de overstap gedaan.

 

De 7 is in bijna alle opzichten radicaal anders (en voor sommige zelfs nog niet genoeg).

 

Hoe je het ook draait of keert, migratie of conversie, de eindgebruiker zal hoedanook iets van de kosten moeten betalen, en als het kan alles.

Het vreemde is nu dat de oorsprong van die kost niet van de klant zelf komt, maar van de leverancier. Het is haast te vergelijken met het geen service/onderhoud meer kunnen krijgen voor een bestaande auto, je moet maar een nieuwe kopen....

 

Komt nog bij dat FM 7 niet zomaar op alle reeds bestaande toestellen kan draaien. Een hardware upgrade is dan ook nog eens nodig. Geen wonder dat je weinig mensen kunt overtuigen....hoe goed het product ook moge zijn, met tal van voordelen.

Dat verandert niks aan het nog steeds goed werkende bestaande, dus waarom aanpassen ?

 

Vanuit ontwikkelaar standpunt vind ik dat een toepassing herschrijven van nul de enige goede oplossing blijft. Er zijn nu eenmaal geen tools voorhanden om alles om te toveren.

Zeker indien het gaat om een complex systeem. En ik vrees dat die er nooit zullen komen.

Voor eenvoudiger toepassingen kunnen bestaande tools (vreemd eigenlijk dat die bijna tegelijkertijd op de markt zijn verschenen) gebruikt worden samen met wat (of heel veel) aanpassingen ‘behind the screens’. Dat hangt af van de originele opbouw.

Maar het blijft wat knutselen. Om eerlijk te zijn kun je dat ook niet goed verkopen, iedere ietswat clevere gebruiker heeft onmiddellijk door dat het kunst, vlieg en plakwerk is, ook al is het professioneel gedaan. De gebruiker krijgt de indruk dat hij moet betalen voor fonkelnieuw tweedehands oplapwerk. Is ook niet bevorderlijk.....

 

Zolang je geen meetbare meerwaarde kunt plakken op het overstappen naar FM 7, zit je blok.

En zeggen dat er op termijn problemen gaan komen indien niet overgstapt wordt naar FM 7 is eerder een dreige-ment dan een argu-ment....

 

Indien je de klant wél kunt overtuigen, zit je weer met het kostenplaatje. André heeft gelijk, je kunt die kosten in totaliteit niet gaan verhalen op de klant, de ‘druk’ komt immers niet van hem uit. En vermits een ontwikkelaar geen liefdadigheidsinstelling is.....

 

Om even naar Rony terug te gaan...ik weet het niet. We hebben hier ook al uren van gedachte zitten wisselen, en zaken uitproberen, waarbij we steeds op 1 punt eindigen, de ‘vernieuwing’ is té radicaal om een ernstige aanpak mogelijk te maken van bestaande toepassingen, zelfs met beschikbare tools...

Of je de toepassingen nu in single of multi file wilt/moet steken.

We kwamen wel tot de conclusie dat je eenvoudige zaken binnen een toepassing multi-table kunt maken, terwijl je de meer kritische zaken beter multi-file maakt, maar dat is een andere discussie...

 

We denken hier dat je als ontwikkelaar tussen wal en schip zit....en kapitein zijnde is dat nu eenmaal geen aangename situatie....

 

(wordt inderdaad nog vervolgd)

[eurotouring]

Ik heb voor mijn bedrijf heel de applicatie zelf geschreven. Ik heb tevens de update versie van FM 7 gekocht en al mijn bestanden geconverteerd. Resultaat: aantal scripts die niet meer werken, relaties die verdwenen zijn. Zelfs FM 7 is verdwenen en terug in de doos gezet. Dze applicatie in FM 6 draait perfect en kan nog velejaren mee.

[AvD]

Zelfs FM 7 is verdwenen en terug in de doos gezet.

 

Als dit niet het citaat van het jaar wordt, weet ik het niet meer...

[WJ]

Beste heren,

 

Ik heb een aantal kleinere systemen overgezet naar FMP7. Ik heb hierbij weinig problemen ondervonden.

 

Groeten,

 

Willem-Jan

[AvD]

Dank, WJ, maar wat je schrijft, wisten we al: voor kleine systemen zijn er weinig onoverkomelijke problemen en de kosten zijn in de hand te houden. Het probleem zit in de grote systemen en de moeilijkheden die daarbij ontstaan.

[AvD]

@Jean

 

Ik denk dat we niet anders kunnen dan het helemaal met je eens te zijn. Je slaat spijkers met koppen! Helaas bevestigt dit alleen maar het probleem. Voor een oplossing zijn we helemaal afhankelijk van FileMaker 7 + x.

[JeanWM]

Voor een oplossing zijn we helemaal afhankelijk van FileMaker 7 + x.

 

 

Laten we hopen dat ze daar in Santa en nogiet kunnen lezen en luisteren.

 

Waar ik moeite mee heb is dat ze gedurende jaren overstapjes probleemloos konden maken. De technieken evolueerden mee, en juist nu, op een belangrijk keerpunt, laten ze 'trouwe' klanten volledig in de kou staan.

De enige die FM van binnen en van buiten kennen zijn de makers, voor zowel de 'oude' als de 'nieuwe' versie.

Het kan toch niet onoverkomelijk zijn om een techniek in te bouwen die de conversie volledig doet.

De techniek bestaat om een robotje op Mars te besturen vanop de aarde, dan kun je toch FM 7 een lagere versie laten besturen ook.

Zelfs indien je een beperking hebt vanuit FM 6, dat zou nog aanvaardbaar zijn.

 

Als je de third party producten bekijkt doen die een soort van pre-controle.

Er bestaat dus een manier om de niet compatible zaken te ontdekken.

Je hebt dus de basis. Waarom dan geen tooltje maken dat daarop verder bouwt.

Vergelijk het met een line-item file. Die zi(a)t ook tussen twee zaken in om het geheel werkend te maken.

 

Maar misschien bekijk ik het te eenvoudig, dat komt omdat ik lid ben van het 'symplistisch verbond'.

[VWin]

Tenminste... tenminste als de klant zo'n upgrade zou willen, EN DAT BLIJKT NU NET NIET HET GEVAL TE ZIJN. Bij alle collega's die we offside al gesproken hebben, horen we dezelfde reactie. Het is kenmerkend in dit opzicht dat van alle grote development-bedrijven geen enkel een complex systeem heeft gemigreerd.

 

De klant met een goedwerkend systeem heeft nog nooit van fmp 7 gehoord, heeft er ook geen horen naar en wenst uiteindelijk dat zijn bestaand systeem blijft draaien.

Natuurlijk weten we dat fmp 7 alles beter zal laten draaien maar hoeveel energie moeten we reeds niet steken in het overtuigen ( financieel ..) van die klient die al tevreden IS met zijn uitstekend( ) programma ?

 

Dus ...mijn indruk: laat ons stapje per stapje werken , maw: als we "traag" werken valt het misschien minder op voor onszelf dat we de fmp7-kosten uiteindelijk grotendeels zelf (zullen) dragen ...

[Durk]

Van een FileMaker insider weet ik, dat FileMaker sinds de eerste Pro versie met dezelfde 'engine' werkte (meer dan twintig jaar!) en dat men dus met de grootste moeite tot aan versie 6 deze oude techniek in leven heeft gehouden. Daarna moest FMI wel met een nieuwe engine komen (security alleen al rechtvaardigde de stap) en tsja, het hele fundament wisselen, daarna ziet zelfs het meest stabiele gebouw er ietwat anders uit.

 

Ondanks anders klinkende geluiden, ben ik er niet zo zeker van of het wel zo makkelijk is om 7 'terugwaards kompatiebel' te maken. En het is maar de vraag of FMI dat ook zo interessant vindt, natuurlijk. Veel liever zien ze iedereen akuut op 7 overschakelen...

 

De stap is te vergelijken met die van OS9 naar OSX. Wat hebben we gevloekt en wat zijn we nu tevreden. Wie weet zien we over een tijdje terug en vragen ons af wat we ooit met die ouwe 5 en 6 versies hebben kunnen doen.

 

Maar helaas zitten we dus nu precies op dat breekpunt. Er blijft weinig anders over dan over te schakelen op 7, hoeveel dat dan ook moge kosten. 5 en 6 leven niet lang meer. Op XP is 5 zelfs al overleden.

 

Misschien is er een lichtpuntje: als deze engine het ook weer 20 jaar uithoudt, zijn de meesten van ons pensioengerechtigd wanneer het nieuwe breekpunt komt

[Rony Rabijns]

De klant met een goedwerkend systeem heeft nog nooit van fmp 7 gehoord, heeft er ook geen horen naar en wenst uiteindelijk dat zijn bestaand systeem blijft draaien.

Weet ik wel, is vaak ook zo, maar wat als ie verplicht wordt om te schakelen om hardware redenen, OS redenen of omdat ie extra licenties nodig heeft ... ? Dan moet je voor die man wel een oplossing kunnen aanbieden ! En daar wringt het schoentje.

[Rony Rabijns]

Ondanks anders klinkende geluiden, ben ik er niet zo zeker van of het wel zo makkelijk is om 7 'terugwaards kompatiebel' te maken.

Larie en apekool ! Als ze één DDR kunnen uitlezen, moet het ook kunnen met meerdere DDR's ineens. Het bedrijf dat dat probleem oplost, is volgend jaar stinkend rijk !

 

De stap is te vergelijken met die van OS9 naar OSX. Wat hebben we gevloekt en wat zijn we nu tevreden. Wie weet zien we over een tijdje terug en vragen ons af wat we ooit met die ouwe 5 en 6 versies hebben kunnen doen.

Deze vergelijking houdt geen steek. Ik ben ook tevreden met de overstap van 6 naar 7. Maar dat is totaal naast de kwestie. Het probleem is de conversie, niet welke versie we nu hebben !

Om je vergelijking toch te gebruiken : mijn documenten die ik gemaakt heb onder OS 9, kan ik wel probleemloos gebruiken onder OS X ! Dat geldt dus NIET voor Filemaker.

 

Er blijft weinig anders over dan over te schakelen op 7, hoeveel dat dan ook moge kosten.

Jij moet overduidelijk niet leven van filemaker-development !

 

Misschien is er een lichtpuntje: als deze engine het ook weer 20 jaar uithoudt, zijn de meesten van ons pensioengerechtigd wanneer het nieuwe breekpunt komt

Wat is dat voor onzin ? Dit rechtvaardigt toch niet dat je na een upgrade maar vanaf nul moet beginnen.

[Rony Rabijns]

Sanne,

jij was voor je werkgever een tijdje terug bezig met een studie over de conversie van 6 naar 7.

Mag ik daar jouw bevindingen over horen ?

[RON7]

@vWIn Daar ben ik het niet mee eens,een klant die zijn licenties officieel heeft en geregistreerd is,is ook meestal op de hoogte van updates.

@ Avd reactie op berichtje:

Probleem is dat hij nu ongeveer de helft van dat bedrag opnieuw moet ophoesten

Misschien ligt daar de fout ook wel een beetje,men overdonderd een klant met een groot bedrag,daarom deed ik het voorstel van een gespreid berekend bedrag wat niet zo hoog moet zijn in totaalkost indien meerdere klanten akkoord gaan.Je krijgt immers ook al geld binnen voor niet uitgevoerde prestaties (rente is spijtig genoeg wat laag nu )

Op deze manier wordt een update toch voor een redelijk percentage door de klant vergoed.

PLUS iedereen zegt hier maar een dat een update grotendeels goed is voor de developer:

1. Men heeft lange tijd uitgekeken naar een verandering zoals 7 er nu een is

2. Wat goed is voor een developer is op termijn ook interessant voor een klant,en bovendien heeft een update van zijn oplossing toch enkele voordelen voor de klant; kunst is die eruit te halen en voor te leggen

[AvD]

@vWIn Daar ben ik het niet mee eens,een klant die zijn licenties officieel heeft en geregistreerd is,is ook meestal op de hoogte van updates.

OK als je die "meestal" vervangt door "af en toe" of "soms". Met alle respect: hoe lang zijn jullie met FileMaker commercial development bezig?

Ik krijg de indruk dat de ouderen onder ons andere ervaringen hebben.

[AvD]

Misschien ligt daar de fout ook wel een beetje,men overdonderd een klant met een groot bedrag,daarom deed ik het voorstel van een gespreid berekend bedrag wat niet zo hoog moet zijn in totaalkost indien meerdere klanten akkoord gaan.

Voor de custom tailored solutions waar het om gaat, is dit natuurlijk niet te doen. Je kan de ene klant niet laten betalen voor aanpassingen aan het programma van de andere. Bovendien moet de kost op voorhand gekend zijn. In IT projects wordt met budgetten gewerkt en een ROI wordt op voorhand berekend. Dat is wat anders dan een digitaal fototoestel kopen op afbetaling. Ik vrees 1) dat het probleem onoplosbaar is in de huidige context en 2) dat we niet op dezelfde golflengte zitten.

[Rony Rabijns]

@ RON7 :

 

De klant wordt niet overdonderd met een groot bedrag. Het is gewoon de realiteit.

Hoe gaat zo'n conversatie er uit zien :

 

Klant : Rony, ik heb een probleem. Ik heb net een extra PC gekocht en daar moet een filemaker 6 op komen.

Developer : Ah klant, maar dat kan niet meer

Klant : hoe zo ?

Developer : je kan geen 6 meer kopen, je kan wel upgraden naar 7

Klant : wat kost dat ?

Developer : een upgrade ? een paar honderd euro.

Klant : is dat alles ?

Developer : nee, ook de bestanden moeten geconverteerd worden

Klant : en wat kost dat ?

Developer : hangt er een beetje van af. In het slechtste geval moeten we overnieuw beginnen met de ontwikkeling.

Klant : ja, ik luister ...

Developer : de tijd dat dat in beslag neemt, is aanzienlijk minder dan de tijd die het tot nu toe gekost heeft.

Klant : en wat krijg ik dan daarvoor ?

Developer : Hetzelfde als wat je nu hebt !

Klant : en daar moet ik dan voor betalen ?

[AvD]

Wat Rony hierboven schrijft is helaas geen circus-sketch.

 

Nogmaals, het herschrijven van een complex pakket - ik denk aan bijvoorbeeld VWin van Erik - is een onmetelijke taak. Vreselijk om daaraan te moeten beginnen. Als je dan slechts één pakket in de etalage hebt, dan kan je nog zeggen "Kom, doorbijten, we halen het wel", maar als het er vele tientallen zijn, elk met hun eigen specifieke eigenschappen, dan zit je met een torenhoog probleem. Ofwel begin je eraan, maar dan moet het betaald worden, ofwel stop je ermee. Program killing heet dat. Dat bestaat dus echt PageMaker is weg, WordPerfect is weg, FileMaker HomePage is weg en zo zijn er nog tientallen...

[Stef]

PageMaker is weg, WordPerfect is weg, FileMaker HomePage is weg en zo zijn er nog tientallen...

 

OK, die zijn weg, maar het reeds opgemaakte is nog bruikbaar in andere programma's.

 

Het grote probleem van FM is dat de data nog steeds niet gescheiden is van de motor, dat je niet met verschillende versies in één databank kan werken. FM belooft dit al jaren, maar het is er nog steeds niet van gekomen.

 

Vergelijk het zo: de data is één groot magazijn waaruit verschillende heftrucks data kunnen halen en aan de gebruiker voorspiegelen, deze kan deze wijzigen en het wordt teruggebracht. Dat die heftruck er eentje is van 1996 of van 2005, of van het merk Mitsubishi of Toyota, dat speelt geen rol, dat het magazijn SQL of Oracle is evenmin.

 

Databaseprogramma's die dit wél doen kennen deze problemen niet, men kan zelfs voor nieuwe modules kiezen welke motor er gebruikt wordt. Ik wil niet het S woord aanhalen, de meeste professionele ontwikkelomgevingen functioneren op deze manier.

 

Zolang de data gekoppeld blijft aan de motor zullen we blijven zitten met conversieproblemen.

 

HTH

Stef

[VWin]

Op XP is 5 zelfs al overleden.

 

Tiens ? Tot op heden hier van nog niets gemerkt !

[EasyKoen]

Toen ik FM7 een goed jaar geleden op mijn macje installeerde was ik net een klein kind dat een nieuw speeltje kreeg. En begon ik vol enthousiasme enkele nieuwe databasejes te bouwen. Met wat vallen en opstaan lukte het me al snel een bestaande oplossing in FM6 te herbouwen in FM7. Reeds van in het begin had ik na een aantal test-conversies door, dat conversie van een bestaande (complexe) oplossing geen optie was, en pure tijdverspilling zou zijn. Ondanks diverse beweringen (onder andere op Devcon) dat conversies, mits in achtneming van enkele regeltjes en een bijna eindeloze whitepaper, weinig problemen zou veroorzaken, heb ik tot op heden geen conversie van 6 naar 7 gedaan. De compromissen zijn te groot en de tijd die je nodig hebt om alles te controleren kan je beter besteden aan iets nieuws (en beter).

 

Maar... er is nog de klant, die uiteindelijk verwacht wordt een rekening te betalen...

Nieuwe klanten : uiteraard geen probleem...

Bestaande klanten reageren meestal een beetje ontgoocheld. En blijven de kat uit de boom kijken. Diegenen die een VLA hebben, bezitten ondertussen een update naar de 7... die in de kast blijft liggen. Niet omdat het een slecht product is maar omdat het voor hun waardeloos is, of omdat ze een meervoud van de licence update moeten betalen voor de aanpassing van hun oplossing. Dus zolang ze FM6 kunnen draaien op Mac OS Tiger en Windows XP, is er geen echt dringend probleem. Longhorn is pas voor eind 2006 dus er is nog wat tijd...

 

Gebrek aan FM6 Licenties : voor VLA klanten is er geen probleem, zij kunnen FM7 licenties bijkopen en FM6 blijven installeren met hun oude code. Voor zover ik weet is het ook nog altijd mogelijk bij aankoop van een volledig nieuwe VLA FM7 een installatiecode voor de 6 aan te vragen.

FM6 retail verpakkingen zijn nog heel moeilijk te vinden, en dan reageert een klant al eens op een minder legale manier. VLA licentiecodes zijn immers vrij gemakkelijk te vinden op het internet... Ik kan begrijpen dat FileMaker Inc wil dat iedereen overschakelt naar de laatste versie, maar je kan je klanten toch niet verplichten een investering, van soms maar 2 jaar, zomaar weg te gooien?

Bestaande bezitters van FM6 zouden de mogelijkheid moeten krijgen om FM6 licenties te blijven kopen. Commercieel gezien kan die voor FMI toch geen slechte zaak zijn? FM6 en FM7 kosten evenveel; ooit gaan die gebruikers toch naar een nieuwere versie en zullen ze dus terug een update kunnen verkopen.

Op dit moment is er nog geen klant van mij die de stap heeft gezet om zijn database te laten herbouwen. Nieuwe klanten daarentegen werken nu allemaal met FM7 oplossingen. Eén klant heeft deze week de stap gezet om een FM7 maatwerk te bestellen om een FM3 database te herbouwen, met de vriendelijke vraag om zoveel mogelijk data te recupereren. Dit is een fikse investering, maar verantwoordbaar, de vorige database is 8 jaar oud, en heeft al heel wat oplapwerk achter de rug, Dit is voor hun administratieve dienst een nieuwe start. Voor bedrijven die 2 of 3 jaar geleden een 10.000 euro geïnvesteerd hebben in een maatwerk zullen nu niet staan springen om opnieuw 5000 euro of meer uit te geven voor een minimale facelift.

 

Koen