Search results

Something well worth noting from a performance perspective is to use named parameters in your pass through routines when running repetitive operations. SQL server will reuse the query plan instead of creating a new one every time. This is a really simplistic example to demonstrate, but instead...

I'm intrigued by what you think this line will achieve: SET [Sales]=Not NZ([Sales],0) I doubt it's what you think? Have you examined the values. Have you tried a simple select query to "see" the possible results? SELECT Sales, Not NZ([Sales],0) as MyNewValue FROM tblProducts

I think 23 years has won... By some considerable margin. 😁

If the combo's are lookups and normally static values then load them into a local cache table on the FE database when you open it. Things like employee lists, state codes, Countries, Currencies etc. that are frequently used and rarely change can and should be loaded into a local lookup table for...

I think I am adding a pretty rare ignore here.

Just a correction: Version 18 of the ODBC driver works fine with Access, we use it with quite a number of clients. Not sure why you would be having issues with it. Edit: apologies I missed both Ron and Tom's earlier reply. Doh!

@dalski If you can get used to writing the queries in SQL Server, the syntax is virtually identical bar a few things (Text delimiters, Date Formats and string concatenation are a couple that spring immediately to mind) Get used to using YYYY-MM-DD. You will then avoid some of the gotcha's...

I'm not aware of any books covering the potentials and pitfalls of using Azure and Access as FE I'm afraid. I have however developed a number of apps with exactly that set up, and most of what I know is based on experience and finding out the hard way... You should move any FE functions into...

Colin has done soe extensive testing on query speeds - this one is specifically on DCount() but it demonstrates that it isn't intrinsically slow. https://isladogs.co.uk/speed-comparison-tests-7/index.html You may be getting confused by the advice to never use a domain function within a query...

Probably not, but it sort of forces the hand of the database. I've used the same method when Access decides it want to capitalise keywords incorrectly. I'm not entirely sure why it works but I assume it "resets" some internal record/value somewhere.

What if you declare it separately as the correct value e.g. Public Const vbDefaultButton2 = 256 Then compile, compact and repair, and check it's value again? Then remove the declaration and see if the correct value sticks?

Bit of a stutter going on here?

I don't know, however it definitely looks like a bug, as installing the 2021 version has cured the issue.

@CJ_London That's a interesting idea, and one I hadn't considered, although there have been numerous reboots.

Is anyone else having issues with LTSC version below? Microsoft® Access® LTSC MSO (Version 2408 Build 16.0.17932.20602) 64-bit I have a client with a mixture of licences and the one above is crashing after initial opening, the will only open in safe mode. The same database file opens fine on...

But do you understand why 🤔

They have only very recently been introduced : https://www.sqlservercentral.com/articles/regular-expressions-in-sql-server-2025

I am happy to be proved wrong but I believe all versions of Azure SQL can have a full text index? I can't see anything here https://learn.microsoft.com/en-us/sql/relational-databases/search/full-text-search?view=sql-server-ver17 that suggest otherwise?

I agree with Colin, I always use the KeyDown event when trapping keystrokes. It never occurred to me to try and use KeyUp.

Change it to a form that looks like a data sheet, then disable the record selector and add a delete cmd button to the end of the record? That avoids the multi select problem and gives a single click to delete the current record.