Search results

@dalski - I edited an error in the SQL after you 'liked'/saw my post - make sure you refresh

Really you only need 2 parameters since the amount of increment is always [SortOrder] + 1; one for the ID of the record, and one to mark where to start the increment. But you can have on for if you are incrementing or decrementing You could have your query SQL like this: UPDATE Tender-HeadersQ...

What is the SQL of query Tender-PgHeadersAdjustSortOrderAQ ? Click on the SQL view button and copy and paste the SQL here

What is the SQL of query Tender-PgHeadersAdjustSortOrderAQ ?

Minty is right - put the operators in the actual SQL. Just pass values in the parameters

Have you checked your References to see if any are marked as missing?

You just have to match to the input type to the return type: Eg Public Property Let PropName(NewValue As Long) ' ... End Property Public Property Get PropName() As Long ' ... End Property ' OR: Public Property Let PropName(NewValue) ' implicit Variant ' ... End Property Public...

Don't you have to declare the property type in the signature? Public Property Get PropName() As Long

I can assure you @Peter Hibbs is no novice! 😂

Sorry, I wasn't aware that you could create a UDF without VBA.

Yes, @MajP already said that in Post #7

AKA 'single quote'

No-one disputes that a parameterised query is excellent for this, but Arnel's code in #2 handles your example just fine too.

How so?

Can you use UDF's in your calculation field? If so, you could try creating a function with unitsInStock as a parameter.

I don't know why you are using an ADODB recordset, but you do realise that an ADODB recordset has a .Clone property that works similarly to the form's .RecordsetClone. So, instead of accessing Me.RecordsetClone, use Me.Recordset.Clone See the docs

Where does VBA come in to this?

They are excel formulas, not VBA, Pat

Did Dvorak delete themself, or have they been banished?

Good catch!