Alabama Road Map

[NauticalGent]

Got a call this morning:

Caller: "John, can you take a look at this form for me, it runs REAL slow....
Me: "Sure! Which one is it?"

I get the info, open up the form and note that it indeed runs sluggish. It is a split form (which I do not like) but probably not the culprit.

So I open up the properties to see what the source is and THIS is what I see...

I love my job...

 

[Minty]

Wow - I hope that PRON is indexed in the source table for the q_PRON query...

 

[NauticalGent]

it is...BUT...although the "Master" PRON table DOES have an AutoNumber PK, he didnt use it on the other tables as a FK. He used to PRON (Purchase Request Order Number e.g. 'AX02F2048A') instead.

And that is just one of many FUBAR's involved. Lots of orphans to contend with.

I keep telling myself "it pays the bills..."

 

[Pat Hartman]

Has it always been slow? If it hasn't, see if they can tell you what changed. I'm afraid that fixing the relationships might break forms and queries and code and you could end up touching every object in the app. I hate getting projects like this. I don't want to extend the kludge but it could cost the client more money than he wants to spend to get rid of all the bad stuff.

 

[NauticalGent]

It has always been slow, relatively speaking, but since the agency has moved to Azure (Citrix VDI) it is MUCH slower.

Changing anything is going to have a cascading effect and they have been warned. Since I am on the 1st year of a 5 year contract, time is on my side!

 

[Pat Hartman]

Have fun

 

[The_Doc_Man]

Damn, and I thought my genealogy project had complex trees...

 

[NauticalGent]

Damn, and I thought my genealogy project had complex trees...

At least your family tree doesn't look like a telephone pole...at least I HOPE it doesn't!

 

[The_Doc_Man]

According to Mark Twain, HIS family tree had but a single branch - and a rope dangling therefrom.

 

[Minty]

If it's on Azure - stick that mess into a SQL view.

Good luck!