(Store) problemer med flytning af et access-program

Har du kikke på de regionelle indstillinger i kontrolpanelet. Her kan man bla. indstille datoformat osv...

... punktet hedder \"International\" i kontrolpanelet; prøv at kikke på fanerne tidspunkt og dato....

Hej Hector (hvorfor har jeg en idé om at det ikke er dit rigtige navn? :o)

På de maskiner, som ikke virker, vil jeg foreslå at du går i VBA-editoren (Alt+F11) og derefter kigger i menuen Tools->References.
I den fremkomne dialogboks, er der en række afkrydset referencer i toppen. Hvis der står \"Missing...\" eller \"Mangler...\" ud for én af dem, er det her fejlen ligger. Så er det formentlig en versionsfejl. Hvis du f.eks. har en referende til Microsoft DAO 3.6 Object Library og der kun er installeret Version 3.51 på maskinen, får du de omtalte fejl.
Du skal så bare udskifte DAO 3.6 med DAO 3.51 (eller hvad det nu måtte være, som mangler)

Jeg håber, at det hjælper.

/Thomas

Det var også min første tanke, at modtagermaskinen ikke havde samme indstillinger, f.eks. at systemindstillingerne var engelske, men begge maskiner har dansk/dansk som bruger-/systemindstillinger.

Desværre var det ikke det, der var galt :-/

Jeg venter lige med at acceptere dit svar Thomas, indtil jeg har tjekket, at det afhjælper alle problemerne :-)

MEN - det var et meget godt hint - nu skal jeg bare have fundet følgende komponenter:

COMcache CcXplore Treeview Control
Arc Informatique Floor Window ActiveX Control

Desværre kan google ikke finde nogle sider, når jeg søger på ordene. Nogle ideer til, hvor jeg kan finde ovennævnte komponenter?

PS - Det er Hektor (med \'k\'), men du har ret i, at det ikke er mit rigtige navn.

Crap! Forkert knap!

Jeg fandt følgende lille forklaring der måske kan afhjælpe dit problem :

International Dates in Access
Americans format dates mm/dd/yy. British commonwealth countries use dd/mm/yy. Koreans and others use yy/mm/dd. In some countries, the date separators are dots or dashes, not slashes. If you are outside the USA, or developing applications that may be used in other countries, you must know to handle dates in Access.
When you type a date into Access, it stores your entry into a number, where the integer part represents the date and the fraction part the time (part of a day). Things can go wrong at three points:
1.    Access misinterprets a date entry.
2.    You fail to format dates correctly in code.
3.    Access does not know an entry should be interpreted as a date.

1. Misinterpretation in the User Interface
Define the date format for your locale in Windows Control Panel | Regional Settings. You can therefore use your local date format when you enter dates into the user interface part of Access: tables, queries, forms, or the Criteria of Query Design View.
Unfortunately, Microsoft tried to be too smart at helping Access accept dates. If you enter a date that is invalid for your local settings, Access spins the date around trying to find an interpretation that works. For example, with British dates in Control Panel, if you enter 10/13/01, Access realises there is no 13th month, and decides you must have intended 13-Oct-01. The results can be bizarre. The entry 02/29/01 should generate an error message that 2001 is not a leap year. It doesn\'t. Instead, Access plays with the entry and decides you must have intended Feb-1-2029 !!!
Aside from this madness (which cannot be turned off), just remember the user interface in Access uses the local Control Panel settings to interpret dates typed into the user interface.

2. Wrong Formatting in Code
In VBA code, delimit dates with the \"#\" symbol. In the 32-bit versions of Access, you must type these entries in American format, regardless of your local settings, e.g. #12/31/1999#. The older Access Basic (versions 1 and 2) followed the Control Panel setting, so watch this difference if you are working with the older versions, or converting old code.
In all versions of Access (including the 16-bit versions), JET SQL clauses require dates in American format. To demonstrate this, enter any date in the Criteria row under a date field in Query Design, and then switch to SQL View. In Query Design view, you see the date according to your local settings, but the SQL statement uses mm/dd/yy format.
SQL clauses are not always obvious, e.g. the Filter of a form, the WhereCondition of OpenReport, or the third argument of a domain aggregate function. Examples:
·    DoCmd.OpenReport \"MyReport\", acViewPreview, , \"InvoiceDate > #12/31/2000#\"
·    Debug.Print DLookup(\"StudentID\", \"tblStudent\", \"EntryDate = #6/30/1953#\")
·    strSQL = \"SELECT * FROM tblDonation WHERE DonationDate > #\" & Format(Me.StartDate, \"mm\\/dd\\/yyyy\") & \"#;\"
The third example demonstrates how to concatenate a date into a SQL string. The Format() function is essential to force the date into American format. Unfortunately, Format() replaces the slashes with the date separator character defined in Control Panel | Regional Settings, so you must specify literal slashes in the format string by preceding the slash with backslashes.
Since this is something you do frequently, you may find it easy to call a small wrapper function for concatenating date strings:
    Function SQLDate(varDate As Variant) As String
        If IsDate(varDate) Then
            SQLDate = \"#\" & Format$(varDate, \"mm\\/dd\\/yyyy\") & \"#\"
        End If
    End Function

3. Data Type not Recognised
There are two cases where Access may not understand you intend an entry as a date.
Unbound Controls
Text boxes bound to Date fields are not a problem, but if the control is unbound (nothing in its Control Source property), how can Access know what data type you intend? If you are in the USA, it will probably guess correctly. If you use another date format, there\'s a high probability that your date will be interpreted wrongly.
In general, the Format property of the control has to do with how Access displays data and does not control data entry. However, if you set the Format property to \"Short Date\" or similar, Access is unable format an invalid entry, so only valid dates are accepted. And since Access now knows the data type, the erroneous interpretations of the date also cease.
As simple as it sounds, setting the Format property is enough to coerce Access into recognising the data type for unbound controls.
Calculated Date Fields
Access can also misinterpret calculated date fields in queries, especially where the date format is not American and the field contains some Nulls. The obvious symptoms are that the field is left-aligned and sorted as strings.
The solution is to explicitly typecast all calculated date fields, e.g.:
    DueDate: CVDate([InvoiceDate] + 30)
(Note: CDate() fails on Null values, so CVDate() has more uses than the \"compatibility\" issue highlighted in the Access documentation.)
With these few simple tricks, you can create databases that can be safely used anywhere, even if the user\'s date formats are different from the developer\'s.