I explicitly included a DB reference as an argument because I basically wanted to take into account unlinked tables from external databases. The test used by @MarkK via MSysObjects will then fail in this form.because I never work outside of currentDB
Of course, one have to initialize this reference before calling it. But that was less of the content of this post. An attentive observer can create a CurrentDb or Opendatabase on their own. Sometimes there are already persistent references that one would then use.
@MarkK
I can share your thoughts on stricter refactoring, especially since I have a comparable function for select queries that returns a recordset. GetQuery and SetParams would therefore be immediately reusable, which means that encapsulation is an immediate advantage.
Like @KitaYama, I see this as a very hard limit that can cost you the overview and create additional overhead.If you write a procedure longer than 8 or 10 lines, start to look for units of work you can delegate to subroutines.
I would be interested to see whether you implement this consistently in your own projects. In any case, one have to put a lot of effort into naming the subroutines in terms of descriptive names.
My limit would be more the number of lines of code that I can read at a glance without scrolling (around 30 - 40 lines).
In my case, directly in the query. Parameters here are given the prefix "par".Where is parametername
used?
Last edited: