plonq: (Oh Come On)
One of my counter-parts out in the head office emailed me today, asking if I could help her pinpoint a problem with one of our databases. She was watching it while the regular person is away on vacation, and it was taking (in her words) forever to run. She though that the query might have hung because it had been sitting for two hours without any change.

I had a look at my own copy of the database (I backed up that folder to a local drive a couple of days ago), and I could not find anything technically broken, so I assured her that it was just a slow network being slow.

Then I started digging into some of the queries this thing was running, and based on what I am looking at here, I would be surprised if it is finished running by this time tomorrow.

I may be misremembering, but I vaguely recall a cartoon that centred around a tree (belonging to either Bugs Bunny or Chip & Dale) getting cut down. The mighty tree got transported to a mill where it went through a number of steps, saws, and milling machines until it was finally used to produce a single toothpick. This database reminds me a bit of that.

This thing connects to a couple of tables in a source database I created for them, and its first query connects to those tables with no limit on the scope. This query is then queried by a second query which cross-references it against the second table to find matching records. Then that query is queried by about eight more queries, each filtering on a single element. Finally all of those queries are joined in a final query, which is the only place she put a limiter on the date (because she only wants the previous day).

Now I have to decide if I want to let this abomination live, or if I am going to quietly re-write it. On the plus side I think that I could probably reduce its run time from hours to minutes, but on the flip side the creator of this database does not handle change well. If I re-wrote this, it would be like walking up and flipping her puzzle table, scattering the pieces everywhere. It's not that I don't want to flip her table, but I'd kind of like to be there when it's flipped.
plonq: (Kinda bleah mood)
Something that I do a fair bit of on this job is combining data from various sources in Access and then pushing it out to Excel and publishing it from there. Normally it works very well, but there is a vexing issue that has caused me a lot of grief over the years.

Sometimes, with no apparent motive that I could find, Excel would remain active in the background, even after I sent it Close and Quit commands. The only way to get rid of it would be to go to the task manager (or Process Explorer in my case) and manually kill it. In some cases this idling version would interfere with other jobs I was trying to run, and other times it would not. This time it did - usually. Either way, it then stacked another idle version of Excel.exe in the background because I obviously needed more ghost processes running.

I finally got pissed about it enough today that I did some research thinking that I could not be the only person encountering this frustrating feature, and I found plenty of hits. Good. More hits increased the odds that I would find a useful answer buried in the usual forum stupid. By "usual forum stupid" I mean answer like these:

"I know you were asking about VBA, but here is the solution in C#"
"I can't reproduce the error."
"Have you tried [something he has obviously tried because it's in the source code he provided]?"
"Have you tried X?" "OK, I tried X and it did not work." "How about X. Did you try that?" "That's the same fucking thing." "I know, but it works for me."

Anyway, after wading fruitlessly through the usual sea of unhelpful responses, was skimming through answers so quickly that I almost missed the one I needed. About three years ago somebody was having the same problem in Excel 2007, and one of the guys in the forum offered up what he thought seemed like a reasonable answer.

"My hunch is that you that you have something that is not tied to an instantiated object. You need to tie everything to the object otherwise Access instantiates another instance of Excel which it then uses for those non explicitly referenced items."

I am pretty good about that, but I poured through my code a few times and then spotted it:

.xlSheet.Range(Cells(iRow,iCol1),Cells(iRow,iCol2).Merge

I fixed it, and the problem went away. I have some other reports that I need to fix (so that I can get rid of the job I created whose sole purpose is to go through every evening and nuke all of these lingering instances). Now if you will excuse me I need to go cut myself.
plonq: (Blah Mood)
I have been beating my forehead on my desk for the past few days trying to deal with an issue in an Access Database I inherited. The problem started the day that I took over ownership of the machine that runs queries on it, so I naturally assumed that the two events were casually related. I did debugging. I re-linked tables. I debugged some more for good measure. I cussed and tore out hear and beat up on computer accessories -- you know, all the usual things that one does when a problem like this arises. No matter how loudly I swore at it though, my query would fail after a few seconds with the descriptive error message, "Invalid argument."

I finally decided that I must be missing something obvious, so I Googled the phrase Microsoft Access "Invalid argument" and the first hit was from the Microsoft support site.

You may receive an "Invalid argument" error message when you run an append query, run a make-table query, or import data in a large Access database file

DING! DING! DING! Hey, an append query is precisely what I am trying to do!

The short answer boiled down to, "MS Access blows up on any database that exceeds 2gb in size. You either need to compact it or split it."

D'oh! How coincidental is that? The day I took over the database is the day that it hit its size limit. I couldn't find any cause linking the two events because there was no cause outside of kismet, and kismet can be a very whimsical thing.

August 2025

S M T W T F S
     12
3456789
10111213141516
171819202122 23
24252627282930
31      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Feb. 5th, 2026 02:28 pm
Powered by Dreamwidth Studios