Recent content by tvanstiphout

I like to know who I'm talking to, but some users choose names that hide their identity. They should be able to do that, no problem. But it would be nice if I could add a nickname to any user's name, to remind me of who they are. This would not breach confidentiality, no user is required to...

Sorry, I could not resist, but this may be a benefit for people working in the quantum realm :)

I used a sproc without any error handling, just simply: select * from sometable where PK = 1 / 0; When executing that with a PT query, the error is caught in VBA, and the Errors collection is populated: ErrorNo=8134 [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Divide by zero...

Hi Pat, I'm assuming this was directed at me, with regards to my testing of DAO caching. Re "If you have a large set of records and never reuse any of them, no cache would help": thas was not my experience. In my tests I scrolled forward ONCE for 10K records. The number of server calls depends...

On the point of DAO caching, I did some research last night, and it is a real thing: I linked to a SQL Server table with Order Details, and opened a DAO recordset with various cache sizes and scrolled forward for 10K records, while also running SQL Server profiler so I could see the traffic...

If that is how you operate: the hour is over, that data is never going to change anymore, let's calculate the numbers and report on them (either now or at end of day, or in bigger reports looking for long-term trends), then I would calculate once, and store in one or more Results tables.

So true. I was tempted to suggest that in first instance :) We need to do everything possible to prevent a successful attack using rainbow tables.

Can we assume the usual: 1, When you say ID field, it is a numeric field 2. The tables have a primary key 3. In the Relationships window, enforced relations have been set up between the tables 4. VisitorSignInDetailsTBL.NameofVisitor is indexed 5. You have a decent computer and used Task Manager...

Yeah, either that, or totally overthinking it and calculating a hash over each physician's account info.

Typically not. The field value is not updated client-side.

Where are you seeing this slowness? How are you deducing this is related to "filtering through the entire list of every field in every table"? Maybe you can post a video of this problem in action?

What is the bigger picture? Did you switch to New Outlook perhaps, and that stopped SendObject from working?

Is it this issue? "SQL Server" ODBC Driver Slow in Monthly Channel (Fixed) (accessforever.org)

> or accessing the stored procedures and functions Look up "WITH ENCRYPTION" clause in BOL.

> you should be able to install an instance of a SQL Server with an SA account for which you have the credentials for Ha! There is the little-known gem that users with full control of the server {e.g. Domain Administrators) can always take control. See for example how to reset SQL Server sa...