Search results

Thanx for the advice guys. But in my queries (and functions) all the evaluation is done using Null Date checks (most evals) and otherwise Date <= Date. The sticking point was that I just learned that I have to return a type "Date" from the custom vba function in order for Access to recognize...

I think I've figured it out (thanx @GPGeorge and @arnelgp). I have 83 fields in the source query, it is a query of a query that has many other queries as it's source. Some of the queries get their data from custom vba functions that are fed other fields in the same source query or table as their...

OK I just created a new blank database, and copied (imported) the form (subform) into it, and then the "format" dropdown worked. But I did not import the source objects, so neither the form or the textbox had valid sources.

Date/time.

Oh yeah, it's the newest version Access Office 365. Version 2412 Build 18324.20194 Click-to-run.

I have an idea for a workaround for this, I can use a custom vba function to strip the time from the date. But I think it may still say [DATE]+ 12:00:00 AM anyway.

Title says it exactly. I click on the dropdown arrow at the right side of the "format" properties, the down chevron to bring up the setting list context dropdown, and all I get is an empty line. I'm reworking a split database to conform to standard database conventions (it never was designed...

Ah, I see now. TY.

Otherwise, I believe I got my answer: there is no significant advantage in marking it indexed. TY all.

Thank you @CJ_London . But I did not have such "indexes" button. So I looked in the ribbon commands, and added it under db "tools" tab, "custom" group. But still, I selected a table in a previous database that I know has multiple indexes and the button remains greyed out and non-selectable...

Recently I have heard from a forum member that one should not mark a table field as "indexed" before adding a query that selects records based on said FK field, claiming that Access will (sometimes?) create a duplicate index (if you create the relationship before marking the FK as indexed or...

So now that I already have, should I turn off indexing, in (table) relationships, for the FK's? I made the FK's indexed first, before adding the relationship(s). Except maybe CashAcctID, I'm just not sure about that one.

HalloweenWeed said: "One thing though, I hate Access comboboxes. I tend to get elaborate with the vba to avoid their use." Just another reason I hate them: I was getting the wrong AcctID value from my AcctID combobox in frmXactnEntryMstr. It was throwing a 'entry needed in tblAcctDirectory'...

So, just to confirm I understand this correctly: I can leave indexing ON for these FK's? That won't cause a fail to make (add) a record if the value is Null? EDIT for clarity: I mean "indexed (duplicates OK)" and field not "required."

OK, it seems my understanding of relationships was not flawed, and I didn't know about the corresponding SQL type associated, but I did perceive the similarity previously. Thank you @mike60smart , that's very helpful. (y) THIS: This is what I needed to know! TY very much @Pat Hartman ...

Yes, I read all comments carefully, and give them thought. I tried reversing the relationship, tried only incl. rows where both fields equal, and still it refused to make a new record. So I had to remove enforce referential integrity, it was the only option that worked for me. Sorry, but I have...

Hello, just noticed this. I have code for a function in a general module, to be used in vba, SQL (Access), or code on controls: Public Function WorkDayNext(SearchDate As Date, NumDays As Integer) As Date '.................................................................... ' Name: WorkDayNext '...

I had to remove "enforce referential integrity" on 3 of my relationships to get the transaction entry form working (frmXactnEntryMstr): Is this bad? I read somewhere something that made me think it was strongly inferring that all relationships should have "enforce referential integrity."...

OK, thank you. I'm currently working the bugs out of the transaction form.

OK, it works (before entry) now. IDK if it works on entry yet, not tested, not the point. But I needed to remove the linking between the master and child forms, then put in this bit of code: Option Compare Database Option Explicit Private Sub Form_AfterInsert() If txtCashAcctID < 1 Then...