problemen met runt-time onder vista

[Bachje]

Beste mensen ik heb een raar probleem

 

ik heb voor mijn studenten een runtime gemaakt om gegevens van een onderzoekje in op te slaan. Zij moeten dan daarna de database aan mij sturen die ik dan inlees in de "moeder database"om zo de gegevens centraal te verzamelen. Onder xp werkt het allemaal prima.

De studenten die de runtime onder vista hebben ginstalleerd (wat overigens prima ging) sturen mij echter een lege database terug. Als zij op hun vista computer de datbase openen krijgen ze gewoon alle gegevens te zien. Als zij het filemaker database bestand uit de map van de runtime (zo heb ik de runtime gemaakt) naar mij toe sturen is die leeg! Blijkbaar hebben de jongens van Microsoft bedacht dat die gegevens elders worden op geslagen. We hebben ons suf gezocht maar kunnen het niet vinden.

Iemand enig idee waar die gegevens worden opgeslagen?

[eroos]

Standaard staat de extentie voor de runtime database op .USR. Wat gebeurt er als je op een VISTA pc de database opent, iets toevoegd en weer sluit? is dan de datum van het databestand gewijzigd?

 

Verder kan ik het mij niet voorstellen dat een OS kan en mag besluiten om de inhoud van je database ergens anders op te slaan dan in de map van de runtime zelf.

 

Ik heb net een runtime gemaakt in Vista. Deze vervolgens geopent in Vista en een wijziging aangebracht. De datum van mijn bestand (naamloos.USR) was gewijzigd na sluiten van de runtime.

 

Kun je aangeven waar je precies op hebt gezocht in je zoektocht naar de data op de pc van de student?

[Bachje]

Beste eroosw,

 

dank voor je snelle reactie....

Ik vond na wat langer zoeken in deze topic posting.php?mode=quote&f=13&p=29756 het volgende bericht dat mogelijk licht werpt op mijn probleem....

 

Deze, Engelstalige, Vista informatie kreeg ik n.a.v. een vraag van 'problemen' bij het installeren van een Filemaker runtime onder Vista. Ik heb er nog niet direct een oplossing voor en ik verwacht deze ook niet gelijk met de Filemaker Runtime Compiler. Stof tot nadenken dus...

 

Virtualization

 

Virtualization is implemented to improve application compatibility problems for applications running as a standard user on Windows Vista. Developers must NOT rely on virtualization being present in subsequent versions of Windows.

 

Prior to Windows Vista, many applications were typically run by administrators. As a result, applications could freely read and write system files and registry keys. If standard users ran these applications, they would fail due to insufficient access. Windows Vista improves application compatibility for standard users by redirecting writes (and subsequent file or registry operations) to a per-user location within the user’s profile.

 

For example, if an application attempts to write to "C:\Program Files\Contoso\Settings.ini", and the user does not have permissions to write to that directory, the write will get redirected to "C:\Users\Username\AppData\Local\VirtualStore\Program Files\contoso\settings.ini".

 

For the registry, if an application attempts to write to "HKEY_LOCAL_MACHINE\Software\Contoso\" it will automatically get redirected to "HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso" or "HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software\Contoso".

 

While developing Windows Vista programs, to reduce the complexity of virtualized files and registry keys, be sure to embed an application manifest with an appropriate requestedExecutionLevel in order to turn off file and registry virtualization.

 

The virtual copy will always be present to the application first. For example, if "config.ini" is available in "\Program Files\ApplicationName\config.ini" and "%LOCALAPPDATA%\VirtualStore\config.ini", the "config.ini" in the virtual store will always be the one read, even if "\Program Files\ApplicationName\config.ini" is updated.

 

Virtualization Recommendations

 

Virtualization is intended only to assist in application compatibility with existing programs. Applications designed for Windows Vista should NOT perform writes to sensitive system areas, nor should they rely on virtualization to provide redress for incorrect application behavior.

 

When updating existing code to run on Windows Vista, developers should ensure that, during run-time, applications only store data in per-user locations or in computer locations within %allusersprofile% (CSIDL_COMMON_APPDATA) that have access control list (ACL) settings properly set.

 

Important

 

Microsoft intends to remove virtualization from future versions of the Windows operating system as more applications are migrated to Windows Vista. For example, virtualization is disabled on 64-bit applications.

 

The following list details other file and registry virtualization recommendations:

 

- Add an application manifest with an appropriate requestedExecutionLevel for your interactive applications. This will turn virtualization off for the manifested application.

 

- Do not use the registry as an inter-process communication mechanism. Services and user applications will have different views of the registry key.

 

- Test your application on Windows Vista: Ensure that processes running as standard user do not write to global namespaces like %systemroot%.

 

- Remember that virtualized resources are per-user copies of global resources.

 

===

 

For more details, see the following pages and documents:

 

http://blogs.msdn.com/cheller/archive/2006/08/24/how-to-embed-a-manifest-in-an-assembly-let-me-count-the-ways.aspx

http://blogs.msdn.com/cheller/archive/2006/12/04/quick-tip-manifests-and-vc-projects.aspx

http://download.microsoft.com/download/a/5/d/a5d3d02a-fd03-466f-9ba8-97f5e7a90a98/CertifiedforWindowsVistaProgramTestCases.doc

http://download.microsoft.com/download/8/e/4/8e4c929d-679a-4238-8c21-2dcc8ed1f35c/Windows%20Vista%20Software%20Logo%20Spec%201.1.doc

 

Dat verklaard misschien mijn probleem.

De bestanden in de instalatiemap onder program files waren onveranderd. De datum was de datum van de aanmaak van de runtime.

Om verwarring te voorkomen heb ik een eigen extentie aan de runtime meegegeven.

Als ik daar op zoek vind hij alleen de datafile onder program files. Mogelijk heeft vista de zaak terug gezet naar .usr?

Wat ik uit de topic begrijp is als iemand geen schrijfrechten heeft (dus niet als adminstrator is ingelogd) Vista een special map gaat maken onder de gebruikers account om daar de betanden, waartschijnlijk verborgen, neer te zetten. Lekker handig.

Bij het zoeken heb gezocht op *.kgp (de extentie die ik gebruik heb) maar ook op databasenaam.kgp in beide gevalen op alle harde schijven die beschikbaar zijn.

Vista meld dan alleen het bestand in de installatie map die onveranderd zijn.

Ik probeer nu een student te bereiken om even in zijn of haar computer te mogen neuzen om te zien of die gegevens in inderdaad onder C:\Users\Username\AppData\Local\VirtualStore\Program Files\dtabasenaam\databasenaam.kgp" staan.

 

Heb jij nog andere suggesties, kun jij dit op Vista reproduceren? ik heb zelf geen vista.

 

Franc

[eroos]

Als de runtime vervaardigt is dan staan alle bestanden in een map die de gebruiker heeft aangegeven. In deze map staat een bestand met de naam die je aan de runtime heb meegegeven. (Zie afbeelding). Klik deze eens met rechts aan en laat het bestand als Administrator uitvoeren. Wat levert dit op?

[hbrendel]

Runtime onder Windows gaat alleen maar goed wanneer je de boel in de home directory van de user zet. Dat was onder XP al zo, maar met Vista is het helemaal nodig. In sommige gevallen (standalone systemen waarbij de gebruiker er verstand van heeft) kan het wel in de Program Files staan, maar wanneer er een systeembeheerder in het spel is, begin daar dan niet aan.

 

Omdat de runtime een programma (.exe) is, lijkt het voor de hand te liggen om de boel in de Program Files te installeren. Maar omdat er bij database toepasingen altijd schrijfrechten moeten zijn, en alle bestanden bij elkaar moeten blijven, is de home directory de juiste plek, want daar heeft de user altijd alle rechten. Dit werkt ook in een netwerk als de home directory op een file server staat.

 

Wanneer meerdere gebruikers (niet tegelijkertijd!) de runtime moeten kunnen openen, dan kan de zaak ook op een share staan, zolang iedereen maar schrijfrechten heeft.

 

Overigens geldt dit hele verhaal ook voor Mac OS.

 

HTH

 

Henk

[hbrendel]

Verder is het nog zo, dat Vista officieel niet wordt ondersteund door FM9, wel door FM10.

 

Mijn ervaring is, dat het in grote lijnen goed gaat, maar er treden af en toe onverklaarbare fouten op, zoals verkeerd sorteren of toch printen nadat het geannuleerd is.

[Bachje]

Beste Henkl en Eroos,

 

dank voor jullie reacties. Het is mij steeds duidelijker aan het worden.

Het vremde is dat de installatie in program files van xp wel goed gaat en dat daar ook het gewijzigde bestand te vinden is maar dat het onder vista helemaal niet goed gaat.

Het zal inderdaad wel met die administrator rechten te maken hebben.

ik heb van te voren op een vista machinen gestest o fh et werkte en dat deed het. MKaar natuurlijk niet gecontroleerd of de wijzigigen in de map van de runtime werden opgeslagen. Zoiets bedenk je niet als je het probleem niet kent.

Ik kan inmiddels niets meer aan die installatie in een andere map dat program files doen. Het kwaad is al geschied.

Ik moet nu zien dat ik de gegevens bovenwater krijg want de zak moet dwe komende week afgewerkt worden.

Ik ga Eroos zijn suggestie even proberen als ik bij een vista machine van mijn studenten kan.

misschien dat dan de wijzigignen wel in het mapje van de runtime worden opgeslagen?

 

wordt vervolgd....

 

Franc

[burggraaf]

Runtime onder Windows gaat alleen maar goed wanneer je de boel in de home directory van de user zet. Dat was onder XP al zo, maar met Vista is het helemaal nodig.

Onder XP kon je gewoon de Program Files map gebruiken. Onder Vista is e.e.a. anders geworden. Vista virtualiseer en haalt daar kort door de bocht gezegd z'n informatie vandaan. De 1e installatie merk je daar weing van maar daarna...

[hbrendel]

Onder XP kon je gewoon de Program Files map gebruiken.

Behalve wanneer de systeembeheerder ... enz. Maar dan kreeg je tenminste nog een error.

[burggraaf]

Kijk onder de gebruikersmap van Vista in de (verborgen) appdata map. Daarin zitten de map local (of locallow) hierin worden deze virtualisaties opgeslagen. Als je ze daar weghaalt dan kunnen er weer nieuwe bestanden worden geschreven. Niet echt een oplossing maar toch...

[Bachje]

Uiteindelijk heb ik het op één computer kunnen oplossen door als administrator het programma op te starten, iets in de bestanden te wijzigen zodat filemaker het databestand opnieuw zou opslaan.

Vervolgens opnieuw in het bestand in de program files map op een andere computer gezet en in het hoofdbestand geimporteerd. Dat bleek te helpen.

Op de tweede computer werkte dat niet. Het databestand in program files map bleef ongewijzigd.

Geprobeerd via de verborgen mappen de data te benaderen maar dan kom je in een woud van rechten terecht. Niet gelukt dus.

Toen had ik een heldere ingegeving. Een nieuwe runtime gemaakt met een andere naam en volledige rechten, en standaard menu's, binnen filemaker zodat ik data kon importeren (stond in de oorspronkelijke runtime uit). Die nieuwe runtme in de map mijn documenten gecoppieerd op de vista machine en gestart en vervolgens de data uit de oude runtime geimporteerd.....en ja wel, dat werkte, ik kreeg keurig alle data te zien.

Vervolgens weer afgesloten en het nieuwe databestand naar de hoofdcomputer gehaald en geimporteerd in het hoofdbestand.

 

Omslachtig maar het is daar mee opgelost.

 

Opmerkelijk is dat op de laatste computer als je daar de runtime starte met administrator rechten je een leeg databestand kreeg. Op de eerste computer niet.

Zal wel ergens in de rechten beheer structuur van vista zitten.

 

Mag ik jullie heel hartelijk bedanken voor het meedenken?

 

Franc

[J.E. Groen]

Heb je de laatste update ook geinstalleerd? Ik had eenzelfde probleem met Vista icm FM9

[Bachje]

Volgens mij werk ik met de laatste opdate 9.0v3

[J.E. Groen]

Inclusief de SSL update?

http://www.filemaker.com/support/updaters/fmp_9.0v3SSL_win_update.html

 

Groet,

Jeroen

 

---------------------

http://www.publishzo.nl

http://www.hoezo14.nl