Schema.ini niet te vinden

[skyrat]

Gegeven : Access 2010 .mdb database, met werkende export naar .csv bestand.
Wat is er gebeurd : uit een tabel zijn enkele overbodige velden verwijderd. De zelfde velden zijn uit de query verwijderd die voor de export wordt gebruikt. De query heeft 2 parameters : 1 voor een boolean veld dat true moet zijn en 1 voor een datum in de query die >= Datum1 en <= Datum2 moet zijn.
Als ik nu weer probeer te exporteren krijg ik de foutmelding :

“De gegevens die u momenteel exporteert, komen niet overeen met de indeling die wordt beschreven in het bestand Schema.ini”

Dus zocht ik naar het bestand Schema.ini maar … dat is niet te vinden. Om zeker te zijn dat ik er niet overheen keek heb ik Windows de hele nacht laten zoeken op alle aangesloten schijven , 's ochtends gekeken en … geen resultaat. Ik ben wel bekend met .ini bestanden, maar als ze niet te vinden zijn wordt het wel heel lastig !! Gaarne enige hulp.

 

[OctaFish]

Vermoedelijk wordt er ergens een exportdefinitie gebruikt (de vertrokken schema.ini). Ik zou de exportregel eens bekijken. Of overnieuw maken.

 

[skyrat]

Wat bedoel je met "exportregel" ? Als ik op "Opgeslagen exportgegevens" klik krijg ik een leeg veld ! En als ik in de macro kijk die de export moet aansturen staat bij Specificatienaam ook niets ! Ook een zelfgemaakte Schema.ini geeft nog steeds dezelfde foutmelding !

 

[OctaFish]

Zo’n schema maken is behoorlijk ingewikkeld, dus als je dat verkeerd doet werkt hij natuurlijk niet. Schema’s hebben ook niets. Te maken met <opgeslagen exportgegevens> dus daar ga je het ook niet vinden. En in macro’s ook niet.
Áls je al een schema wilt gebruiken, moet dat in dezelfde map staan als het import- of exportbestand.
Hoe dan ook: mijn tip blijft gewoon staan: maak de export opnieuw. En niet met een macro, maar met VBA.

 

[skyrat]

Inmiddels had ik al een paar tests gemaakt via Externe gegevens --> Exporteren --> Tekstbestand en dat gaat redelijk simpel. Het probleem is nu echter dat dat niet lukt als er in de query een WHERE staat met daarin bijv. qryQNaam.Datum >= forms!frm_Formnaam!DatumVan AND qryQNaam.Datum<= forms!frm_Formnaam!DatumVan (kan natuurlijk ook met Between, maar gaat hier alleen maar om een voorbeeldje). Access kan dat kennelijk niet aan en komt met een melding dat er minstens 2 parameters moeten zijn. De vraag is dus nu hoe ik dat weer moet oplossen, want het gaat er juist om dat de gegevens alleen over een bepaalde periode moeten worden geexporteerd naar een .csv bestand.

 

[OctaFish]

Probeer eens om de parameters toe te voegen. Maar ik snap niet dat je, als je het toch al vanaf een formulier aanstuurt, ook niet afmaakt op dat formulier. Met dus één regeltje code .

 

[skyrat]

Voor mij als volslagen leek op Access gebied begrip ik je antwoord niet. De query die geexporteerd moet worden heeft al de juiste parameters en werkt op zichzelf goed (dus alleen als query). Maar Access ziet geen kans om de export te verzorgen (WEL zonder de parameters, maar dan wordt ALLES geexporteerd !). Hoe zou dat ene regeltje er dan volgens jou uit moeten zien ?

WEER een dag klooien verder zonder echt op te schieten !
Als je met 1 regel code bedoelde : DoCmd.TransferText acExportDelim, enz. dan heb ik dat ook al geprobeerd, maar ook daar loop ik dan tegen de Export Specificatie aan. Wat ik ook invul, er komen altijd weer foutmeldingen. Het zou heel fijn zijn als je nu met echte , duidelijke hulp zou willen komen. Dinsdag (vandaag) moet ik weer naar de eigenaar van het programma en kan ik dus alleen maar zeggen dat het nog steeds niet werkt !!

 

[OctaFish]

Zonder db wordt het voor ons lastig om concrete tips te geven, zeker omdat ik het probleem niet kan reproduceren. Noch kan ik ruiken wat je al gedaan hebt. Je vertelt ook nu pas dat je TransferText al geprobeerd hebt.... ik ben geen helderziende!
Daarnaast (echt wel een tip) zou ik afstappen van criteria waarin je naar formuliervelden verwijst. Dat gaat vaak fout in exports. Vele malen beter is het als je de filtering ‘hard’ in je SQL programmeert. Probeer hem maar eens met harde datums in het criterium i.p.v. je formulier verwijzingen. Goeie kans dat-ie het dan wél doet.

 

[skyrat]

Uit het feit dat mijn post al bijna 100 keer ( !!!! ) bekeken is blijkt wel dat dit een bekend probleem is in Access. Anderen begrijpen dus waarschijnlijk WEL wat het probleem is ! Het probleem is toch in weze heel simpel : als ik de query met een WHERE clausule met ALLEEN vaste waarden wil exporteren dan gaat het goed met een knop op een formulier. Maar dat is natuurlijk geen optie ! Het moet toch mogelijk zijn om een door een gebruiker in te voeren begin- en einddatum voor de query te gebruiken ? Op zich werkt die query daarmee dan ook prima, alleen de export lukt niet !
Ik hoop echt dat er nu eindelijk iemand met een oplossing kan komen, want ik ben er langzamerhand doodziek van !!!

Ik begrijp ook niet dat je het probleem niet kan reproduceren. Neem een simpele tabel met persoonsgegevens en daarin een veld met een datum (bijv. "Registratiedatum") en maak een eenvoudige query die alle personen toont met een Registratiedatum tussen "Begindatum"en "Einddatum".
Op een form staan dan een knop "Exporteren" en 2 invoervelden voor "Begindatum"en "Einddatum". Bij de Gebeurtenis van knop wordt dan de DoCmd.TransferText acDelimited,..... uitgevoerd. Is het ZO duidelijk wat ik wil ????

 

[OctaFish]

Ik weet allang wat jij wil, maar jij snapt mij dus niet. Nogmaals: ik kan jouw probleem niet reproduceren. En ik heb deze constructie in het verleden ook meer dan genoeg keren zonder probleem toegepast.
Dus nogmaals de uitleg wat je even moet proberen (en dat is dus niet: exporteren zonder filter want dat werkt). Zet in je criterium een datumfilter met echte datums, en geen velden uit een formulier. En kijk of dat wėl werkt.

 

[skyrat]

Beste Octafish,
ik begrijp je wel degelijk !! Wat ik niet begrijp is waarom je, als je mijn constructie wel begrijpt en al vele malen probleemloos hebt opgelost, je niet gewoon even kan zeggen hoe je dat dan hebt gedaan. En dan op een voor een volslagen leek op het gebied van Access begrijpelijke manier
Gisteren ben ik weer een hele dag (tot 22.00 uur) bij de opdrachtgever bezig geweest met allerlei andere problemen. Tussentijds heb ik wel regelmatig gekeken of er nog Octamail was, maar toen dat er nog steeds niet was zat ik dus met een zeer teleurgestelde opdrachtgever !
Ten einde raad heb ik toen maar eens op enige buitenlandse sites gekeken en .... binnen enkele minuten had ik een oplossing te pakken :thumb::thumb::thumb:. Weliswaar was het een export naar Excel, maar vandaag heb ik dat dus kunnen ombouwen naar csv export . En het werkt !!!!
Gezien het grote aantal kijkers naar onze discussie (132 !!) zijn er kennelijk vele mensen die belangstelling hebben voor dit onderwerp en waarschijnlijk nu nog steeds wachten op een duidelijke oplossing.
Dit is niet bedoeld om je af te kraken (ik geloof best dat je dit werk met de beste bedoelingen doet) maar ik heb het idee dat je door jouw jarenlange ervaring met Access het gevoel voor nieuwkomers bent kwijtgeraakt.
Veel sukses verder.

 

[OctaFish]

Weliswaar was het een export naar Excel, maar vandaag heb ik dat dus kunnen ombouwen naar csv export .

Kijk, als je mijn eerste antwoord in bericht #2 had gelezen, dan had je dat punt dus al op 1 december bereikt. Ik zei toen al: overnieuw maken.

 

[OctaFish]

Gezien het grote aantal kijkers naar onze discussie (132 !!) zijn er kennelijk vele mensen die belangstelling hebben voor dit onderwerp en waarschijnlijk nu nog steeds wachten op een duidelijke oplossing.

En die 136 (de teller loopt gewoon door) mogen jou persoonlijk mailen om die oplossing ook te krijgen?

 

[skyrat]

Wat jammer dat je de strekking van mijn laatste bericht en voorgaande berichten niet hebt begrepen. Als je goed had gelezen had je gezien dat ik al lang bezig was om te trachten een nieuwe export te maken maar dat ik geen enkele voor een nieuwkomer begrijpelijke aanwijzing kreeg hoe dat dan moest
Wat de vele kijkers betreft : het is jouw taak om ze tevreden te stellen ! Lijkt me een goeie oefening voor je om in voor iedereen begrijpelijke duidelijke taal de oplossing te geven. Misschien is die uiteindelijk wel hetzelfde als degene die ik nu op een andere site gevonden heb :d:d

 

[OctaFish]

Wat de vele kijkers betreft : het is jouw taak om ze tevreden te stellen

Hier vergis je je een beetje. We proberen als helper (onbezoldigd, geen enkele status of connectie binnen HelpMij, volledig in eigen vrije tijd) vragenstellers met hun vragen de goede kant op te sturen. Het is zeker niet onze taak om lezers tevreden te stellen. Als andere mensen dat antwoord kunnen gebruiken (dat begint bij: snappen wat er staat, goed de omstandigheden kunnen interpreteren etc) is dat prachtig, dan heeft de vraag een algemeen nut. Als andere lezers ofwel niet met het antwoord uit de voeten kunnen (andere omstandigheden, andere inrichting etc) ofwel het antwoord niet snappen, staat het ze vrij om een eigen vraag aan te maken.

Als we al een 'taak' hebben, is het om de vragensteller van goede antwoorden te voorzien. En zelfs dat valt in de categorie: "garantie tot de deur". Daarnaast hebben wij geen enkele boodschap aan welke deadline dan ook. Zoals gezegd: het is allemaal liefdewerk-oud-papier, dus het zou heel dom zijn om als TS verwachtingen te baseren op levertijden van oplossingen. Voor mij is het heel simpel: als ik een avond geen zin heb om achter de computer te kruipen, doe ik dat niet.

Daarbij zijn we dus ook afhankelijk van wat de vraagsteller aanlevert, zowel qua omschrijvingen als qua materiaal. Een Access vraag zonder database is bijzonder lastig te interpreteren, omdat je dan als helper niet kan zien wat er allemaal in de db gebeurt wat een probleem kan triggeren. Dat de tips dan wollig kunnen zijn, is logisch. Ik probeer echt wel duidelijk te zijn, en volgens mij lukt dat ook redelijk, maar het moet wel van twee kanten komen. Dus als ik een specifieke vraag stel (bericht #8) dan verwacht ik ook van jou te horen dat je dat a) hebt getest, en b) wat daar de resultaten van zijn geweest. Maar wellicht was dat al een deel van de verwarring .