Invoice. Dirty fix or redo? (1 Viewer)

JJ,

No problem. It is actually a sample I've been wanting to do for a while. That was about a half hour to set up. I'll be doing a more detailed version soon.

It is geared so you can extend your "Parts" quickly by simply adding more records. Putting in "Categories" is a good idea for my demo, and I'll probably be adding that in the next few days.

jjatwork said:

This journey started with me hearing about an opening and mocking up a simple 'LOOKUP/EDIT/DELETE' mySQL db with a terminal-based UI in python

Click to expand...

Actually, though not identical, it was similar for me. I was doing mainframe work and my boss told me about an Access DB being used to track computer assets. At the time, we were in the 600-700 system count and a fellow named Gene (not known to this forum) had cobbled together something to track what we had and build reports. I had done some formal DB study on the mainframe using an ORACLE system that was our BE package and a mainframe-based FE package called SmartStar. The boss said he wanted someone to back up Gene because he was floundering.

Like you, I was aware that the more you did for the boss, the more he would do for you when review-time came around. So I took over and started fixing a GOD AWFUL MESS of a database for which the term "relational" applied only because the description on the back of the original software box used that word once or twice. Got it to work, cleaned it up, made sense of it, Gene left, and then a year later the government took it over. The guy who took it from me claimed to know Access but at the time I saw no evidence to support the assertion. So, I moved on, pooch got screwed, project fell into the dirt due to the negligence of the government person who now owned it, and time passed.

But here is ANOTHER lesson to be learned. Your reputation follows you. So the boss had ANOTHER project suitable for Access and remembered my name. Sort of like a criminal record that follows you around, so to speak. (Which is why I NEVER admitted to understanding COBOL!)

To make the boss happy, I took that one on doing a similar sort of thing to the first one but with more emphasis on security than resources. Also by this time the site had reached 1200-1500 servers across 60-80 projects (the dashes representing growth of the site over six years). Oh, I learned a lot. Including the old adage, "no good deed goes unpunished."

The down side is working with people who didn't know what they wanted and trying to second-guess them. The up side is that my career with the Navy as a contractor lasted a total of 28 1/2 years of steady, reasonably lucrative employment until I was ready to retire. Just walk into the melee with your eyes open and your mouth shut.

Since the thread hasn't been closed yet, I'll provide a small update.

I've been studying up on normalization and trying to clean up the DB. Lots of trial and error had resulted in some redundant code and tables/queries. Additionally, I've nearly finished removing any sensitive data from the DB and translating it into english, so I have it ready for upload, should it become necessary.

I'll probably be asking quite a few question, so I'm considering how best to go about it.
Would it the best manner to make 1 large thread, to avoid spamming the forum, or make several, more specific threads, so other people, with the same question/problem, can find a more concise answer when they do a search?

Thanks again to you all. I've taken the advice to heart and read the links.
Mark, I haven't been able to look at your example yet. No unauthorized files on the workstations, but my supervisor is working on a solution.
I'll definately have a look at it when things are sorted out.

Normally you start 1 thread for 1 question. This allows you to keep an eye out for solutions to THAT question without having to read dozens of pages of unrelated information. Likewise it allows others to search for the same issue without having to dig through a discussion on squirrel migrations to find what they need.

Thank you. That was exactly my thinking, I just wanted to make sure.
JJ

Adding to Mark_'s answer, I suggest that splitting topics up assures that at least some of the questions get faster answers because the contrary method jams a bunch of questions together at once. As an example, I am not up on SQL Server issues in detail, only in general overview (though I understand ORACLE better). And I am a hardware, security, and operating system guy based on background. But others would come from other backgrounds and have different strengths. So splitting questions up lets EACH of us with certain specialties to jump in where we are comfortable and hope that others can take the things we aren't so sure about.