Search results

1400 usd per month? Say what ?! Here in the NL health insurance is 110 euro per month... which I guess with exchange rates now a days equals about 1300 dollars but still ;)

Just to add my 2 cents, deleting data and/or messing with your source data is a matter of last last last last last resort. Leave your data as is and summarize your data in a query as suggested, this is the way to go.

Best solution to me seems to be a model form in tabular format, which is made to look like a message box... but that is my 2 cents

yes real hard to put money into a savings account each month and pay every six months... I pay several insurances per year and save 100s of euro per year because of 5 seconds of work.... best payed 5 seconds every year.

Another reason to stop using Macro's ... as far as I know, no not possible.

Old people are road hazards... atleast thats what some insurance companies claim... time to retire Jon? Insurance premiums offcourse go + inflation - additional no claim, in the NL at some point you reach the max at - no claim and all you are left with is the + of inflation (and/or the plus of...

With docmd.transferspreadsheet you can define a range to import into a table Import into a temp table and pick up the ID you nee with a query, shouldnt be too hard to do.

which tbh is nonsense, with or without the "is not null" in the first column doesnt make a difference in showing the "Watch" records.... something else has become different to make it work for you.

Yay! Now its readable :) duedate >= x and duedate <=y This is the same as your original duedate between x and y ! So what else has changed to make it work ?

actually yes its needed... sql gets the values but has no clue what they are and has to guess as to their purpose. This is implicit conversions and are the source of many a trouble in any database.... it works while it works untill it breaks for whatever reason and starts giving false results...

As per my first line.... you dont. You do this like with your "open cases" query .... in a query

Try using a date that is ambigues (spelling) like 01-08-2020 ... Jan 8th or Aug 1st? This is where troubles arrize, disambiguating is very very important... Note the lack of # on the OP for starters

Most likely problem is that in sql you need the date format to be in US format i.e. MM/DD/YYYY, where you are using DD/MM/YYYY Second likely problem is your date in your database includes a time component, i.e. 07/31/2020 08:33:45 and you are looking from 07/31/2020 to 07/31/2020 this will not...

You would be better of using a single query instead of using 4 dcounts which in essence is 4 queries. Your dcount would work with Dcount("[ID]" ,"[Open Cases]"," [Opened Date] >= #" & Date() & "# and [Opened Date] >= #" & Date() + 1 & "# ") You obviously have some idea about naming...

Untestested, but maybe: Selection.hyperlinks(IngTemp).TextToDisplay = ""

Your intended FK probably has values that are not in your PK column select * from tblStandardMeetingInvitees where M_ID not in ( Select M_ID from tblMeetings) Should list your problematic records

One of the key things for a database to use an index is for it to consider it current. PK indexes on integer values are always current because new values only get added. Thus rebuilding the index will not help much. Varchar indexes tend to go out of date much faster.... they tend to be less...

erm in theory yes, in practice... Building an execution plan is usually not the problem...

The difference between varchars and integers is far less noticable now a days, but the difference is definately there... If only because varchars tend to be longer and less sequential vs integers. 20 years ago it was really really noticable....

Do you mean the cast?? Main problem remains, finding the records which is slowed considerably by 1) Beeing a varchar 2) not having an index.