Zoek programma/programmeertaal voor conversie-applicatie

[mikekiwi]

Ik ben voor mijn werk op zoek naar vervanging voor een bestaand programma. Ik werk bij een bedrijf waar we behoorlijke hoeveelheden data verwerken.
We krijgen verkoopbestanden van winkels in enorm veel verschillende formaten (xls, csv, ascii en daarbinnen weer vele variaties in bestandslayout) en deze moeten worden omgebouwd naar een uniform, reeds vastgesteld csv-formaat.
Het zou dus gaan om een applicatie die alle van de winkels ontvangen data (in 400 verschillende formaten/lay-outs) converteert naar één vaste lay-out.

Het is dus eigenlijk niets meer of minder dan een conversieprogramma; ombouwen van één formaat naar een ander formaat.

Maar…. dan wel met een paar extra’s, want zo simpel als hier boven gesteld gaat het niet. Ik moet bijvoorbeeld ook meerdere bestanden gezamenlijk kunnen inlezen en dan samengevoegd kunnen exporteren. Of 2 bestanden met verschillende inhoud samenvoegen (1 omschrijvingenbestand en 1 verkoopbestand, samen te voegen op een gedeeld id).

Per winkel moet kunnen worden opgeslagen in welke kolom (excel of csv), positie (ascii), of regel (ascii, verspreid over meerdere regels) ik welke variabele kan vinden.
Bij variabelen moet je denken aan barcodes, omschrijvingen, prijs, verkoopaantal, etc. Deze staan bij elke winkel op een andere plaats en dit moet vastgelegd kunnen worden.

Ik hoop dat ik het een beetje duidelijk heb uitgelegd, zo niet, dan lees ik dat hier wel…

Mijn vraag is dus: zijn er kant-en-klaar programma’s waar ik dit mee kan doen of kunnen jullie een programmeertaal aanraden om dit mee te doen? Het gaat er dan ook om dat mensen met niet al te veel programmeerervaring (basis in SAS) voor een nieuwe winkel een nieuwe conversie moeten kunnen opbouwen.

Verder zou het praktisch zijn als ik met hetzelfde programma of software ook wat relatief eenvoudige analyses op die (of andersoortige) data zou kunnen loslaten met queries.

Ik ben benieuwd of iemand wat suggesties zou kunnen geven hoe en/of waarmee ik dit zou kunnen doen…

Thanx!

[TheGhostInc]

Klinkt in mijn oren als dat het tijd wordt voor een database?

Want die acties die je nu beschrijft zijn typisch van die dingen die je makkelijk doet met een database, of alvast een programma dat daarop gebaseerd is.
(Bv Access, en in mindere mate Excel)

[Freee!!]

Als eerste even een heel praktische vraag: Op wat voor platform moet die conversie draaien Dat is namelijk wel van belang bij het bepalen of er al zoiets is, danwel welke programmeertaal/talen je kunt gebruiken bij het schrijven van het één en ander.

Als je er eenvoudige queries (en latere minder eenvoudige) op los wilt laten, denk ik dat het toch handig is om de uiteindelijke csv-file nog een keer om te zetten naar iets dat iets gemakkelijker te doorzoeken is (met minimaal een index dus).

[TheGhostInc]

mikekiwi schreef op vrijdag 19 november 2004 @ 15:17:
[...]
Mijn vraag is dus: zijn er kant-en-klaar programma’s waar ik dit mee kan doen of kunnen jullie een programmeertaal aanraden om dit mee te doen? Het gaat er dan ook om dat mensen met niet al te veel programmeerervaring (basis in SAS) voor een nieuwe winkel een nieuwe conversie moeten kunnen opbouwen.
[...]

BTW.
Kun je even uitleggen waarom iemand met weinig programmeerervaring (basis in SAS, sorry, maar het zegt me niks, een of ander financieel pakket volgens google) een *nieuwe* conversie moet gaan maken voor een *nieuwe* winkel.

Houtje touwtje is leuk, maar als projecten groot worden, moeten ze automatisch professioneler. Als het kan, gewoon vanaf de grond opnieuw opbouwen, en zoveel mogelijk meuk dumpen.

[brokenp]

Ik denk niet dat hier bestaande oplossingen zijn, maar ik denk dat je voor dit doel het beste een scriptingtaal kan gebruiken (perl, python ,PHP ofzoiets)

Ik denk dat je per invoerformaat een script moet definieren.

[Freee!!]

brokenp schreef op vrijdag 19 november 2004 @ 15:29:
Ik denk niet dat hier bestaande oplossingen zijn, maar ik denk dat je voor dit doel het beste een scriptingtaal kan gebruiken (perl, python ,PHP ofzoiets)

Ik denk dat je per invoerformaat een script moet definieren.

Die talen ken ik niet, maar ik zou hiervoor waarschijnlijk een paar COBOL-programmaatjes schrijven. Overigens zou ik xls eerst door Excel om laten zetten naar een csv en de csv daarna verder bewerken (indien nodig).

Een andere manier om de zaken aan te pakken, is die winkels vertellen dat ze het op een bepaalde manier aan moeten leveren, maar ik neem aan dat die mogelijkheid al onderzocht en uitgesloten is.

[onkl]

Excel kan je zonder twijfel gebruiken. Wordt je niet gelukkig van, maarhet zal wel goed gaan.
De vraag is of je dat wilt.
Als ik je verhaal lees heb je meer behoefte aan systeem-analyse dan een programmaatje.
Ga eens praten over een vastgesteld formaat door het hele bedrijf/ alle klanten / etc.
Het probleem met iedere oplossing is dat je nu een oplossing verzint maar nooit zeker bent of volgend jaar bestandsformaat numero 500 nog een beetje leesbaar is voor je.
Misschien kan het wel niet (werdt niet duidelijk uit je verhaal) maar ik denk dat als de kans er is je die het beste kan pakken.

[mikekiwi]

OK, even wat reacties:

Onze huidige oplossing is geprogrammeerd in SAS en daar wordt per winkel een script geschreven. Werkt prima, wordt gedaan door mijn afdeling en we kunnen daar prima mee overweg. Met weinig programmeerervaring bedoel ik dat men wel inzicht heeft in dit gedeelte van het programma (het inlezen, manipuleren van data e.d.) maar dat men geen complete applicatie kan bouwen.

Een database bouwen is niet nodig, het uiteindelijk gecreëerde uniforme formaat wordt ingelezen in een redelijk grote internationale database (Oracle, verder geen verstand van versies o.i.d.), dus daarin is al voorzien...

Alles zou moeten draaien op WinXP.

Toevoeging: het moet een applicatie worden die door meerdere mensen tegelijk gebruikt moet kunnen worden, ook via een Terminal Server omgeving (geen idee of dit belangrijk is, maar toch)

Nee, het is geen optie om hetzelfde formaat van iedereen te ontvangen (was het maar zo... )

Excel is geen optie als basis, er zitten bestanden tussen van >1 miljoen records.

Het mooiste zou een front-end zijn met GUI, waarbij ma selecteren van winkel en periode een script wordt aangeroepen die de data dan ombouwt...

[ Voor 17% gewijzigd door mikekiwi op 19-11-2004 15:45 ]

[brokenp]

Ik denk dat je voor dit specifieke probleem geen bestaande software kan vinden.
Je hebt nu een paar oplossingen:
- Je gaat zelf/intern iets scripten/programmeren
- Je gaat op zoek naar een professioneel bedrijf (incl het prijskaartje...)
- Je zoekt een student/bekende die dit voor je maakt (geen kwaliteitsgarantie als bij bedrijf)

[mikekiwi]

de vraag naar een bestaand programma was ook een beetje tegen beter weten in om heel eerlijk te zeggen.

Uitbesteden kan, maar als laatste redmiddel (kosten aspect). Een student zou een optie zijn, maar geen idee of dat te doen is. Uitzoeken van een goeie lijkt mij lastig...
Zelf schrijven/scripten is een mogelijkheid, maar in welk programma??? Ik zoek dus een programma dat redelijk snel veel records kan verwerken, met veel verschillenden formaten overweg kan (opslaan van Excel naar csv van te voren doen we nu ook, dus het direct inlezen van Excel is geen vereiste), en een niet al te steile leercurve heeft...

Is MS Visual Foxpro een aardige optie?

[Freee!!]

Ik denk dat de vraag welk programma of welke programmeertaal het gemakkelijkste te beantwoorden is door te kijken wat er al aanwezig is aan:
• programma's en/of compilers/interpreters (inclusief licenties)
• kennis en ervaring van al aanwezige medewerkers (en hun voorkeuren)

Ik ken Foxpro niet, dus over de geschiktheid daarvan kan ik geen uitspraak doen. Wat ik wel weet, is dat er teveel mogelijkheden zijn om zo op te noemen.

[P_de_B]

Hmm, dit klinkt alsof je Biztalk nodig hebt. Wel duur, maar dan heb je ook wat

[Johnny]

Ik heb laast een presentatie over Cordys bijgewoond, daar werdt verteld dat het ook bijna alle mogelijke bestandsformaten kon afhandelen, maar daar moet je natuurlijk wel voor betalen...

[TheGhostInc]

* TheGhostInc snapt er even helemaal niks meer van, en heeft het even proberen samen te vatten:

(vertaalt naar een voorbeeld, je lijkt niet zo happig op namen geven te zijn)
Stel je bedrijf levert... computeronderdelen van merk A, assortiment 1 t/m 100
Jullie leveren uit aan een stel winkels, B, C en D, en elke winkel stuurt jullie digitaal
verkoop cijfers terug, in een "eenvoudig" formaat. Afkomstig uit kassasystemen van
verschillende merken/generaties etc.

Wat je dus eigenlijk wil is:
Je selecteert je bestand
Je selecteerd een filter (of winkel/kassasysteem)
Je output de data in een standaard formaat

Vanuit dat standaard formaat gaat het dan richting je oracle database.

Volgens mij kan elk zichzelf respecterende (script) taal dit.

Waarom kom je met moeilijke scenario's over terminal server en andere moeilijke dingen?
Het is toch niet meer dan bestand selecteren, filteren en klaar?
Of zijn er nog meer dingen die moeten kunnen.

Ik vermoed dat als je hier serieus aan begint dat er meer vragen en verzoeken komen, kijk daar mee uit. Het ene moment ben je een beetje aan het scripten, het volgende moment staat de afdeling verkoop en inkoop aan je tafel omdat ze meer willen.

[Zerora]

Als ik zo eens dit verhaal lees. Dat er dus een nieuwe applicatie geprogrammeerd moet worden. De eisen die je noemt is vrij moeilijk lijkt mij om inelkaar te zetten. En daarnaast gaat er erg veel tijd in zitten om al die conversie scripten te maken.

Als ik een van de eerdergenoemde keuzes zou moeten kiezen:

- Je gaat zelf/intern iets scripten/programmeren
- Je gaat op zoek naar een professioneel bedrijf (incl het prijskaartje...)
- Je zoekt een student/bekende die dit voor je maakt (geen kwaliteitsgarantie als bij bedrijf)

ZOu ik gaan voor het zoeken naar een professioneel bedrijf. Deze heeft immers genoeg ervaring met dergelijke scripten (hoogstwaarschijnlijk). En is de garantie dat je applicatie goed werkt ook een stuk groter.

[Boss]

Je bent dus niet op zoek naar een database, zoals foxpro. Je bent op zoek naar een omgeving waarin je met veel verschillende formaten kan werken. De applicatie hoeft alleen maar data te pompen en zelf niets op te slaan in een eigen database.

Ik heb zoiets wel eens gemaakt in Delphi. Met de juiste componenten kan je daarmee zo'n beetje ieder formaat wat er wereldwijd te vinden is uitlezen. En zeker de formaten die voor jou van belang zijn.

Het probleem is niet zozeer de omgeving. Het zou inderdaad ook in VB, PHP, Perl of wat dan ook kunnen. Ook in die talen kan je verschillende formaten lezen.

Het probleem dat je wel hebt is dat je een applicatie moet hebben die 'klaar is voor de toekomst' en waarin de beheerders van het programma (dus niet de makers/programmeurs) later eventueel nieuwe conversies kunnen definieren.

Technisch is het allemaal peanuts. Data formaat A lezen -> data formaat B schrijven is niet echt spannen. Het lastige is om een omgeving te maken voor de gebruikers waarin ze zonder achterliggende kennis er toch mee kunnen werken.

Dus... welke programmeertalen beheers je, en ga daarmee aan de slag.

[Verwijderd]

hm, interessant probleem.

Simpel gezegd, moet je een programma hebben wat:
- Een diversiteit aan bestandsformaten kan inlezen
- Uit deze bestanden bepaalde data kan halen
- De geëxtraheerde data in één bepaald formaat kan wegschrijven

Je hebt dus nodig:
Een interface om te bepalen welke data je uit een bepaald bestand moet halen,
en naar welke kolom deze data weer moet in je 'export' bestand.

Ik doe zoiets maar dan in een hele simpele vorm met m'n clieopgen, echter deze slaat definities (nog) niet op.

Als bij jouw eenmaal een bepaald bestand soort is gedefinieerd zou je dit aan de hand van de kolomnamen (en de volgorde daarvan) weer kunnen herkennen en automatisch verwerken.

Ik weet zo 123 niet of hier bestaande oplossingen voor zijn, maar het maken van een programma als dit zou idd niet al te moeilijk zijn. Meeste tijd gaat zitten in de interface met de gebruiker waarschijnlijk.

[Pinobigbird]

TheGhostInc schreef op vrijdag 19 november 2004 @ 22:20:
[...]
Volgens mij kan elk zichzelf respecterende (script) taal dit.
[...]

Helemaal mee eens. De keuze van de programmeertaal ligt dan aan de voorkeur en ervaring van de programmeur die dit voor je gaat maken.

Ik zou er niet voor kiezen om zoiets met Excell oid te doen.

De tip om een student hiervoor te gebruiken lijkt mij een goede.
Plaats een advertentie oid bij een (bedrijfs-)informatica studie. Gegarandeerd dat je reacties krijgt.

Juist omdat het relatief eenvoudig is, is het zonde hiervoor (te) veel geld voor te betalen aan een professioneel bedrijf.

[mikekiwi]

@BrokenP: inderdaad een script per invoerformaat. lees: per winkel is dus >450 inleesscripts

@Mr.Liu: ik heb geen idee wat er nu aan software/licenties (behalve sas) aanwezig is; hoogstwaarschijnlijk zullen we hoe dan ook van scratch af aan moeten beginnen

@TheGhostInc: samenvatting is min of meer correct; ben inderdaad niet happig om namen te noemen... Het toevoegen van moeilijke scenario's doe ik niet om de boel ingewikkelder te maken, het zijn dingen uit de praktijk waar we nu problemen mee hebben. De huidige software werkt alleen lokaal en niet op centraal op 't netwerk en dus moet ik met mijn medewerkers min. 1x per week de geschreven scripts synchroniseren om iedereen een up-to-date versie te geven. En dat is niet ideaal en heeft in het verleden problemen opgeleverd.
Uiteraard wil ik dus dat de nieuwe oplossing centraal op het netwerk wordt geinstalleerd, zodat iedereen vanaf waar dan ook in hetzelfde programma met dezelfde versie zit te werken.
Onze afdelingen verkoop/inkoop hebben in feite niets met deze applicatie te maken; zij werken met deze data via de genoemde Oracle-datawarehouse oplossing en hebben daar alles tot hun beschikking...

@Rakkerzero: dank voor je advies: het is zeker een niet uit-te-sluiten optie; ik wil echter eerst kijken of het op een andere manier kan alvorens de portemonee echt opengetrokken gaat worden

@Boss: Nee, database is niet noodzakelijk, maar ik weet dat er in Foxpro wel eens dergelijke oplossing zijn gecreëerd, vandaar de suggestie.
Delphi is dus één van de mogelijkheden, interessant; ben ik geen expert in, maar heb de beginselen onder de knie. Haal het woordje "eventueel" maar weg bij het maken van nieuwe conversies; het is aan de orde van de dag, min. 2 per week worden er toegevoegd.
Overigens is het niet per sé noodzakelijk dat de medewerkers zonder achterliggende kennis er mee moeten werken. Scholing is waarschijnlijk onvermijdelijk...als blijven het geen mensen die van nature programmeurs zijn; het zijn data-analisten met wat programmeerervaring.

@maui71: goede samenvatting en ben het eens met je conclusie: het maken van een goede opzet van het creëren van inleesscripts en het creëren van de scripts zelf gaat het meeste tijd kosten.
Het is niet zo dat de oplossing binnen een maand compleet moet staan; Er is een gefaseerde overgang gepland die wel eens >1 jaar kan duren

[Verwijderd]

Misschien kan je hier eens naar kijken:
http://www.softinterface.com/Convert-XLS/Convert-XLS.htm

Of heb je liever een op maat gemaakt programma ?

[ Voor 22% gewijzigd door Verwijderd op 20-11-2004 15:24 ]

[Verwijderd]

Pinobigbird schreef op zaterdag 20 november 2004 @ 15:01:
[...]
Juist omdat het relatief eenvoudig is, is het zonde hiervoor (te) veel geld voor te betalen aan een professioneel bedrijf.

Ik denk dat het bedrijf van TS toch wel bepaalde garanties en zekerheden wilt hebben betreffende de software. Ik zeg niet dat een professioneel bedrijf het beter zal doen als een student, maar als je het bij een bedrijf 'ordert' kan je
natuurlijk wel wat strakkere afspraken maken, en de kans op continuiteit van je 'leverancier' is wat zekerder.

[Maanzaad]

Als je ASCII als invoer hebt (bv. in CSV formaat) dan is misschien AWK een oplossing voor je. AWK heb ik jaren geleden gebruikt en is volgens mij nog steeds gratis te krijgen. Met AWK kan je met behulp van Reguliere expressies (iets als "Als het 3e woord op de regel met $<spatie> begint dan voer regel uit in formaat xyz").

Reguliere expressies zijn bijzonder krachtig, maar je moet er wel even mee gespeeld hebben om door te hebben hoe je het probleem het beste kunt aanpakken. Je de denk wijze aanleren. AWK is dus een soort script taaltje. Ook het combineren van bestanden is volgens mij mogelijk. En soms moet je met tussenbestanden werken omdat (complexe) bewerkingen (conversies) niet in een slag te maken zijn. Zoek is op het Web en speel er is mee.

From the WEB:
The Awk text-processing language is useful for such tasks as:
- Tallying information from text files and creating reports from the results.
- Adding additional functions to text editors like "vi".
- Translating files from one format to another.
- Creating small databases.
- Performing mathematical operations on files of numeric data

Het verbaast me overigens wel dat er zo aangeklooid wordt met zoveel winkels. Garantie voor problemen lijkt me. Wat kost het als de gegevens verkeerd in de Oracle DB komen (of te laat)? En wat kost een goede oplossing?

[mikekiwi]

Verwijderd schreef op zaterdag 20 november 2004 @ 15:24:
Misschien kan je hier eens naar kijken:
http://www.softinterface.com/Convert-XLS/Convert-XLS.htm

Of heb je liever een op maat gemaakt programma ?

Ha, deze ken ik al...; inderdaad en zeer veelzijdig, maar niet veelzijdig genoeg. Ik kan daar mee een paar excelbestanden omzetten, maar zit dan nog steeds met mijn txt-bestanden met >! miljoen records. En ik wil toch echt één oplossing voor alle winkels en niet 4 of 5 verschillende proggies voor een groep data...

[Verwijderd]

misschien offtopic, maar wat is de oorzaak dat je de bestanden in zo'n grote diversiteit krijgt aangeleverd? (werk je soms bij het cbs ??) . Is er niet een mogelijkheid om de bron van alle ellende op te lossen, dus dat er een uniform formaat wordt aangeleverd?

Want zoals 'maanzaad' al zegt, dit soort praktijken zijn of worden zeer vaak een bron van ellende.

Hier is de laatste tijd wel een en ander over te doen: http://www.xbrl.org/Home/ (nieuwe hype )

Het lijkt me handiger om op basis van bv xbrl iedere winkel een mogelijkheid te geven om zo de data te exporteren (excel plugin, maken, en dat soort zaken). Jullie verzamelen daarna alleen nog maar de verschillende xbrl bestanden, echter door hier uniforme tags/structuur in te gebruiken wordt het importeren eenvoudiger, en meer integer !

[ Voor 29% gewijzigd door Verwijderd op 20-11-2004 15:41 ]

[mikekiwi]

Maanzaad schreef op zaterdag 20 november 2004 @ 15:31:

Het verbaast me overigens wel dat er zo aangeklooid wordt met zoveel winkels. Garantie voor problemen lijkt me. Wat kost het als de gegevens verkeerd in de Oracle DB komen (of te laat)? En wat kost een goede oplossing?

Hela, wie heeft het over aanklooien??? De huidige oplossing in sas werkt prima, maar is niet ideaal (om verschillende redenen). Zeer effectief en betrouwbaar, nog geen bestand is fout in de database terechtgekomen, anders dan door menselijke fouten. Foute data in de database wordt zo goed als voorkomen door een Quality Management programma voordat de data daadwerkelijk in de Database wordt gezet.

Dank voor de tip over AWK, ik ga daar zeker 'es naar kijken...

[mikekiwi]

Verwijderd schreef op zaterdag 20 november 2004 @ 15:38:
misschien offtopic, maar wat is de oorzaak dat je de bestanden in zo'n grote diversiteit krijgt aangeleverd? (werk je soms bij het cbs ??) . Is er niet een mogelijkheid om de bron van alle ellende op te lossen, dus dat er een uniform formaat wordt aangeleverd?

Want zoals 'maanzaad' al zegt, dit soort praktijken zijn of worden zeer vaak een bron van ellende.

Hier is de laatste tijd wel een en ander over te doen: http://www.xbrl.org/Home/ (nieuwe hype )

Oorzaak: veel verschillende winkels met verschillende kassa-systemen in verschillende landen = veel verschillende data. Wij kunnen een winkel niet verplichten om een bepaald systeem te gebruiken, dus moeten we zelf voor de conversie zorgdragen...

[Maanzaad]

mikekiwi schreef op zaterdag 20 november 2004 @ 15:39:
[...]


Hela, wie heeft het over aanklooien??? De huidige oplossing in sas werkt prima, maar is niet ideaal (om verschillende redenen). Zeer effectief en betrouwbaar, nog geen bestand is fout in de database terechtgekomen, anders dan door menselijke fouten. Foute data in de database wordt zo goed als voorkomen door een Quality Management programma voordat de data daadwerkelijk in de Database wordt gezet.

Nou ja, met dat aanklooien bedoelde ik de menselijke component in de conversie. Ik begrijp dat je niks kunt doen aan de invoer. Maar vooral als dit herhalende handelingen zijn (1x per week /maand) dan loont het zich om zoveel mogelijk te automatiseren. Maar ik lees dat er al een redelijk goed vangnet ter controle is ingevoerd. Succes verder met AWK of een andere kandidaat.

[Space29]

Zelf doe ik regelmatig conversies, alhoewel die over het algmeen eenmalig zijn. Wat mij hier heel goed bij helpt is SQL server.
- Deze kan zo'n beetje alle door jou genoemde bestandformaten importeren
- is in een client server model te gebruiken
- Hij kan gekoppeld worden aan Oracle.
- Import en export taken zijn planbaar en kunnen geautomatiseerd worden.


Nog één tip, ga geen scripts gebruiken voor het importeren. Deze zijn daar niet voor gemaakt en hebben er veel meer tijd voor nodig. Voorbeeld: adressenbestand van 140000 records. PHP doet er twee uur over en met delphi kan het in 3 minuten.

[Boss]

Nog één tip, ga geen scripts gebruiken voor het importeren. Deze zijn daar niet voor gemaakt en hebben er veel meer tijd voor nodig. Voorbeeld: adressenbestand van 140000 records. PHP doet er twee uur over en met delphi kan het in 3 minuten

Met scripts heeft TS het volgens mij over importdefinities, die vervolgens door een parser worden ingelezen (die dan bijv weer in Delphi gemaakt is) zodat je verschillende kolommen etc. kan opgeven in het script.

[mikekiwi]

Boss schreef op maandag 22 november 2004 @ 16:47:
[...]


Met scripts heeft TS het volgens mij over importdefinities, die vervolgens door een parser worden ingelezen (die dan bijv weer in Delphi gemaakt is) zodat je verschillende kolommen etc. kan opgeven in het script.

Yep, helemaal gelijk. Misschien een wat verkeerde term in dit verband, maar dat is inderdaad wat ik bedoel...

[Boss]

Heb je inmiddels al een keuze gemaakt voor wat betreft de taal waarmee je aan de slag gaat? Op zich kan dit best nog wel een handig programma worden

[mikekiwi]

Boss schreef op dinsdag 23 november 2004 @ 09:22:
Heb je inmiddels al een keuze gemaakt voor wat betreft de taal waarmee je aan de slag gaat? Op zich kan dit best nog wel een handig programma worden

Nog geen definitieve keuze gemaakt; er zijn nu 2 opties die overblijven:

1. Visual FoxPro: niet de beste optie wellicht programmatechniosch gezein, maar ik kan wellicht van een gelieerd bedrijf een vergelijkbare applicatie overnemen en dat dan ombouwen naar lokale behoeftes. Scheelt een hoop denkwerk en het programma heeft zich qua snelheid en stabiliteit al bewezen

2. Delphi: als optie 1 niet doorgaat ga ik zelf iets in Delphi creëren; is erg krachtig naar ik heb begrepen en er zijn redelijk wat additionele componenten te verkrijgen die het inlezen van veel verschillende formaten vergemakkelijken...

Dank voor de reacties zover, heb een hoop geleerd inmiddels!

Groet,
Michael

[ILUsion]

Delphi wil ik zeker aanraden!
Volgens mij moet je niet per winkel maken, maar gewoon één applicatie. Die applicatie laat je bepaalde bestanden laden en onderzoeken. De verschillende soorten bestanden zet je in een DLL of PascalScript (heb ik zelf geen programmeerervaring mee, maar heb het wel ZEER succesvol in Ant Movie ( www.antp.be ) geïmplementeerd gezien, waarvan je trouwens de code onder GPL kunt gebruiken. Die applicatie kun je ook een connectie laten leggen met een database, let er wel op dat je per bestand een controle inbouwt, want kleine winkels gebruiken vaak wel een Excel-bestand maar de ene keer formuleren ze het op de ene manier, de andere keer anders en in andere velden.
Ik hoop dat je hier toch al een stukje verder mee bent. Voor standaard in Delphi wil ik je www.delphibasics.com aanraden maar je mag me natuurlijk ook iets vragen (over de taal zelf, de componenten verschillen natuurlijk van gebruik)