Differences in date management between Win10 and Win11 (2 Viewers)

[amorosik]

I have a procedure created with Access 2013 ver 32bit that runs on Windows 10 pro
It uses data present on Firebird 3.0 and the tables are connected via odbc using the odbc driver version 2.0.3.154
Everything works correctly
I pass the same project on a Windows 11, Access same version, Firebird db always 3.0, odbc driver always 2.0.3.154, and I see that during the selections, on some forms the filter is modified, the dates give a problem, it seems that the selection no longer works in the sense that it returns an error 3146
I investigate the code and I see that the error occurs precisely when applying the filter and therefore on the line with the me.Filter.on instruction
The complete line passed to the Filter property is of this type
" MATTINA_POMERIGGIO='P' and CREAZIONE_DATA = #05/15/2025# and CREAZIONE_IP_ADDRESS = '172.24.64.1' " and I assume that it is the CREAZIONE_DATA field that gives the problem
That 05/15/2025 indicates May 5 2025, and on Win10 pro it works perfectly
I checked the odbc driver settings and they are identical
What could be different on Win11 compared to Win10?

 

[AHeyne]

How about the regional settings in Windows? Maybe they differ from one computer to the other?

 

[arnelgp]

runtime error 3146 is odbc error.
can you manually check with the server, how CREAZIONE_DATA is being saved.

 

[amorosik]

runtime error 3146 is odbc error.
can you manually check with the server, how CREAZIONE_DATA is being saved.

The db field type is TIMESTAMP

 

[amorosik]

How about the regional settings in Windows? Maybe they differ from one computer to the other?

Date format, Currency format, Time format, are identical

 

[The_Doc_Man]

I don't know if it is applicable, but apparently using the same exact driver for win10 and win11 isn't always right.

ODBC Native Client 10 Performance Issues After Windows 11 Update - Microsoft Q&A

A legacy application using ODBC Native Client 10 has encountered significant performance issues following the latest Windows 11 update. The application previously worked well, but now it is unacceptably slow. The environment includes an in-house MSSQL…

learn.microsoft.com

I haven't used ODBC in years and can only offer a suggestion to investigate what this article suggests. If this is not relevant, sorry to waste your time. But it's all I could quickly find that seemed relevant.

 

[amorosik]

I don't know if it is applicable, but apparently using the same exact driver for win10 and win11 isn't always right.

ODBC Native Client 10 Performance Issues After Windows 11 Update - Microsoft Q&A

A legacy application using ODBC Native Client 10 has encountered significant performance issues following the latest Windows 11 update. The application previously worked well, but now it is unacceptably slow. The environment includes an in-house MSSQL…

learn.microsoft.com

I haven't used ODBC in years and can only offer a suggestion to investigate what this article suggests. If this is not relevant, sorry to waste your time. But it's all I could quickly find that seemed relevant.

Mine is "Firebird odbc driver"
Native Cliente 10 is for Microsoft Sql Server

 

[DHookom]

I would experiment with some different values and delimiters in a query and a pass-through query.

 

[amorosik]

I would experiment with some different values and delimiters in a query and a pass-through query.

The problem is not getting the program to work
Probably if I reverse month/day everything starts to work
The real problem is:
- why it works with Win10 and doesn't work with Win11 ???
Same program, same db server, same odbc driver, same Access runtime

 

[sonic8]

- why it works with Win10 and doesn't work with Win11 ???

In absence of any better idea, I would recommend to turn on ODBC Trace and review the generated log file to find out whether the problem arises because Access submits the date in a different format or whether the ODBC driver interprets an unchanged date format differently.

 

[CJ_London]

I would expect Timestamp is not the same datatype as a date field - same can be seen in sql server date2 datatype.

It may be win 10/2013 is less concerned about it than win11/365. I would look for solutions suggested for the date2 datatype

 

[sonic8]

I would look for solutions suggested for the date2 datatype

The solutions are either don't use it or use a driver fully supporting it. - I don't think this is applicable here, as it is the very same driver in both scenarios.

 

[The_Doc_Man]

One of the articles I looked up when researching the original question addressed the driver code issue. A Microsoft-hosted tech site claimed that the driver paradigms between Win10 and Win11 are the same. I.e. the internal device data structures didn't change across versions. That means that the same driver you used for Win10 should run correctly for Win11. Since the device structures didn't change, the odds favor that the problem isn't a security setting made during driver installation.

This problem will more than likely be due to either different Windows settings OR different driver settings between the two O/S's OR different application settings in the Access FE that talks over ODBC to its BE database.

 

[AHeyne]

I accidently read this very current article: https://borncity.com/win/2025/05/16/issues-with-visual-c-redistributable-and-odbc/
Maybe there is a relation to your problem with this library?

 

[AHeyne]

@sonic8 : As you're german too: There is also a german version of this article, having many comments maybe be interesing to be read too.

 

[arnelgp]

what i've discovered on my search is that Timezone field type in firebird do actually store the hours:min:secs (+millisecs).
so you might change your query to something:

" MATTINA_POMERIGGIO='P' and (CREAZIONE_DATA BETWEEN #05/15/2025 00:00:00# and #05/15/2025 00:00:01#) AND CREAZIONE_IP_ADDRESS = '172.24.64.1'

 

[sonic8]

There is also a german version of this article, having many comments maybe be interesing to be read too.

Thank you, that's indeed interesting.
It's quite peculiar that there are many reports about financial software like DATEV and SFirm being affected, but not much else. I would have expected a much wider variety of reports considering that the problem should affect many (all?) ODBC drivers.

 

[GPGeorge]

FWIW: Interestingly, I recently found that there are significant problems with Date and DateTime fields when connecting PowerApps to SQL Server. I know, not in the same stack as the problem discussed here, but perhaps relevant in that the workaround I came to was to convert all dates and datetimes to strings before passing them to SQL Server as parameters for Stored Procedures and letting the Stored Procs convert those strings back to the proper dates or datetimes. It's extra handling on both sides, to be sure, but in the end, it was the way I found that I could be sure everybody was on the same page. This was particularly a problem when the parameters were declared to accept Nulls.

In a later revision, though, I figured out a way to avoid passing those dates as parameters at all, so the problem was resolved differently. In case you're wondering, I resorted to supplying defaults for that set of date fields. I'll have to add back the method of handling them if I decide to modify the workflow in a later phase of the project to allow an admin override of the default dates.

The point, of course, is that, as arnelgp points out, in different environments, there can be discrepancies in the standard formats applied to date and datetime fields that are subtle and quick to anger.