data afdrukken via een ander bestand

[jw]

Natuurlijk heb ik al mijn tabellen in een bestand samengevoegd.

Zo is er ook een bestand met adresgegevens.

Daarin kan de gebruiker zoeken en zo een selectie samenvoegen.

 

Nu wil de deze selectie vanuit een fysiek ander bestand printen.

( om de printlayouts van de gebruiker bijeen te houden )

 

Wat voor een soort relatie moet ik tussen beide leggen om de gevonden records vanuit het printbestand te kunnen zien?

[Joris Aarts]

Wat voor een soort relatie moet ik tussen beide leggen om de gevonden records vanuit het printbestand te kunnen zien?

 

Hallo,

 

mijn eerste gedachte:

Adressenbestand: verzamel alle adresID's van je found set via een loop-script en gooi ze onder elkaar (met returns gescheiden) in een global field van een tabel van het mailing-bestand.

Leg een relatie van die global in het mailingbestand naar het adresID-veld in de tabel met adressen. Wat je nu krijgt is een vele-vele relatie omdat je global meerdere ID's bevat. Via de script-step 'go to related record' (show only related records) kan je nu vanuit die ene global op elk gewenst moment de found set van het adressenbestand weer oproepen.

Dit kan handig zijn als je bijvoorbeeld een historiek van je mailings wil bijhouden: je kan de inhoud van die global dan per mailing in een historiek-record bewaren. Zo kan je later nog perfect nagaan naar welke adressen je ooit een welbepaalde mailing had verstuurd.

 

Veel groeten,

 

Joris

[jw]

Joris, dank voor je antwoord.

Dit is zeker een oplossing, maar binnen het netwerk en dan met bijvoorbeeld 1000 records of zo gaat dat tijd kosten.

 

Omdat je binnen in Filemaker 7 kan overstappen van de ene layout naar een ander (beem me up scottie) met behoud van de set gevonden records hoop ik dat dat op een of andere manier ook kan als je de gevonden recordset wil vasthouden als je naar een gerelateerde layout gaat die zich in een ander bestand bevindt.

 

Is er iemand die hier uitsluitsel kan geven.

[Joris Aarts]

Hello,

 

Waarom bouw je de zoek-functionaliteit niet in het printbestand zelf? Of is het expliciet de bedoeling dat functionaliteit en gebruikerslayouts gescheiden blijven?

 

'Beam me up" zal in jouw voorbeeld niet werken want dan zou je naar een table occurence in een doelbestand moeten kunnen jumpen die gebaseerd is op een base table van het bronbestand. En ik heb het geprobeerd: het gaat écht niet.

 

OK, verzamelen van de ID's is tijdrovend. En als je nu de zoekopdracht zelf eens zou 'opvangen' en op één of andere manier als script-parameter doorgeven aan een ander zoekscript in je printbestand (Waarom niet ineens in SQL? )

[Koen Van Hulle]

Dat is nu eens een leuke vraag. "Beamen" zal inderdaad niet lukken, want bij de optie "Go to related record" kun je geen externe layout aanduiden.

 

Ik heb hier geen kant-en-klare antwoord op, ik ga even het één en ander moeten uittesten.

 

 

Koen

[jw]

Het gaat er inderdaad om de printfunctie geheel los te koppelen van de databestanden. Hierdoor kan je in een toepassing zorgen dat de huisstijl an de klant gescheiden blijft van de applicatie. Bovendien kan je de gebruiker meer vrijheid geven in zijn eigen afdrukken.

 

Daarom is het geen oplossing om de zoekactie te verleggen naar het printbestand omdat je dan een deel van de functionaliteit overzet.

 

Verder; je kan de zoekactie wel overbrengen, maar daarna gaat de gebruiker met 'omit' nog wat records scrappen en daarmee is de zoekactie, en ook de weergegeven volgorde niet meer overdraagbaar.

 

Een andere oplossing zou ook kunnen zijn: een import van alle records uit het bronbestand, alleen hal je dan slechts de key binnen. Daarmee het je zowel de willekeurige selectie als de volgorde te pakken en dat werkt veel sneller dan het verzamelen van de keyvelden om dat een portaal op te zetten. Alleen dat werkt al in fm6 en daarvoor, en hoop op een betere methode met fm7.

[Sanne]

Murtje, ik zit voor jw meer te denken aan een oplossing waarbij op privileges-niveau via een filereference alleen-raadpleeg-toegang wordt gegeven op specifieke velden (de "kerstkaarten-actie").

 

Dat zou de gebruiker toch toestaan om geheel vrij in zijn eigen database de rapporten (= layouts) te maken, gebruik te maken van alle records (inclusief zoeken) van het databestand, maar zonder dat via die eigen database de gegevens veranderd kunnen worden?

 

Hoewel, als ik jw goed begrijp, wil hij juist de functionaliteit van het "zoeken" niet laten plaatsvinden in het print-bestand

[jw]

sanne, je zegt het goed.

 

Ik bouw een applicatie om deze bij verschillende klanten te installeren, daarbij wil ieder zijn eigen huisstijl = afdruklayouts kunnen hebben en beheren. Als ik de basisapplicatie aanpas en uitlever dan vervang ik de printmodule niet.

 

( Verder heb ik nioet zoveel op met specifieke gebruikers en rechten op veldnivo in de verschillende layouts. Het lijkt mij een onoverzichtelijke janboel omdat je dan layouts, scripts, gebruikersrechten, tabellen en tabeloccurences en ook nog op veldnivo in rechten vanalles moet afstemmen, bijhouden, ik ben dan het overzicht kwijt. Maar dat is even buiten het onderwerp. )

[Rony Rabijns]

... de "kerstkaarten-actie"