Re: Serious Problem with Date in RecordSource



Hmm. Yes, this is ODBC data, not JET data, so some if the things I suggested
won't apply.

I can't see that the 4-digit year option will make any choice for the
literal dates in the SQL string.

The AutoCorrect property of the control won't make any difference: that
determines only whether Access performs spell-checking as you enter, and is
unrelated to the problems with attempting to track changes to field names.

Not sure what else to suggest for you. We always test if the form is dirty
and explicitly save the record before assigning RecordSource. It's useful to
force all pending events to be triggered, but I am not aware of a specific
bug that this would address in your case.

Perhaps someone else will have some suggestions.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"José António Silva" <JosAntnioSilva@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:11A9095F-F3DF-4B04-B096-CB1D437164EC@xxxxxxxxxxxxxxxx
> Thanks Allen, but I think that this cannot be the problem, because:
>
> a) I have debugged the jet and nothing is sent to the server. So, it can't
> be an index problem.
> b) Everything is running ok until I migrate to ODBC and SQL Server. I'm
> constructing the recordsource and the date format with VB and I'm not
> dependent of Autocorrect issues.
> c) I deploy the application in mde format and I use Custom Startup Wizard.
> It is always decompiled.
> d) I have the InsertionDate field in a subform but I don't have child and
> parent fields because the main form has no data source.
>
> This is a far bit stranger because in my computer everything is running
> ok.
> In other computers with the same operating system and ODBC version the
> problem remains.
>
> In the sequence of your response I will test the database with four digit
> year format enabled and autocorrect disabled in the insertion field. It is
> already disabled in tools general tab.
>
> José António Silva
>
> "Allen Browne" wrote:
>
>> Jose, the crash could be caused by several things, such as:
>> a) a bad index on the date field;
>> b) a corruption caused by Name AutoCorrect;
>> c) a corruption of the VBA code;
>> d) a bug in A2002/2003 if the form has/is a subform.
>>
>> To solve:
>> a): Repair the database: Tools | Database Utilities | Compact/repair.
>> b): Disable the Name AutoCorrect boxes: Tools | Options | General.
>> c): Decompile the database.
>> d): Add a text box to the subform for the field named in LinkChildFields.
>>
>> Suggested sequence:
>> ================
>> 1. Uncheck the boxes under:
>> Tools | Options | General | Name AutoCorrect
>> Explanation of why:
>> http://allenbrowne.com/bug-03.html
>>
>> 2. Compact the database to get rid of this junk:
>> Tools | Database Utilities | Compact
>>
>> 3. Close Access. Make a backup copy of the file. Decompile the database
>> by
>> entering something like this at the command prompt while Access is not
>> running. It is all one line, and include the quotes:
>> "c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
>> "c:\MyPath\MyDatabase.mdb"
>>
>> 4. Open Access, and compact again.
>>
>> 5. Open a code window.
>> Choose References from the Tools menu.
>> Uncheck any references you do not need.
>> For a list of the ones you typically need in your version of Access, see:
>> http://allenbrowne.com/ser-38.html
>>
>> 6. Still in the code window, choose Compile from the Debug menu.
>> Fix any errors, and repeat until it compiles okay.
>>
>> At this point, you should have a database where the name-autocorrect
>> errors
>> are gone, the indexes are repaired, inconsistencies between the text- and
>> compiled-versions of the code are fixed, and reference ambiguities are
>> resolved.
>>
>> If it is still a problem, the next step would be to get Access to rebuild
>> the database for you. Follow the steps for the first symptom in this
>> article:
>> Recovering from Corruption
>> at:
>> http://allenbrowne.com/ser-47.html
>>
>> --
>> Allen Browne - Microsoft MVP. Perth, Western Australia.
>> Tips for Access users - http://allenbrowne.com/tips.html
>> Reply to group, rather than allenbrowne at mvps dot org.
>>
>> "José António Silva" <JosAntnioSilva@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
>> message
>> news:62B303DC-CB78-4BD0-B9F9-BD798C54A8D0@xxxxxxxxxxxxxxxx
>> > Anybody knows the reason Access 2003 crashes when I filter data in a
>> > form
>> > with a date field?
>> >
>> > I'm setting the recordsource to: SELECT Guia.* FROM guia WHERE
>> > Guia.InsertionDate = #7/28/2004#
>> >
>> > I also have tried #2004-07-28# but the crash remains.
>> >
>> > Table Guia is a linked ODBC table to SQL 2000.


.



Relevant Pages

  • Re: Nameless CREATE
    ... The starting point is either an existing database or one that is ... "Describe" involves issuing an SQLDescribeCol function to ODBC ... essentially much the same as character data type apart from all 8 bits ... ALTER TABLE tablename ADD COLUMN BinaryColumn BINARY ...
    (comp.lang.forth)
  • Re: fields queries and utter disaster
    ... Unfortunately the \c ODBC DATABASE field switch is not supported in Word ... of course supports ODBC connections but Word ... Mac Word Test ... suggests that it should be possible to use query files (cf. .qry/.dqy ...
    (microsoft.public.mac.office.word)
  • Re: [VW 7.3.1] ODBCConnection
    ... I played around with a few combinations on the connection string and ... with a trusted SQL Server connection. ... there are differences for database connects. ... > any database specific odbc drivers. ...
    (comp.lang.smalltalk)
  • Re: CDatabase, CDaoDatabase
    ... raw ODBC calls ... DAO will outperform ODBC (and so CDatabase) considerably in single user ... There is considerably more to database performance than making quick ...
    (microsoft.public.vc.mfc)
  • Re: CDatabase, CDaoDatabase
    ... raw ODBC calls ... DAO will outperform ODBC (and so CDatabase) considerably in single user ... There is considerably more to database performance than making quick ...
    (microsoft.public.vc.language)