|
It is the little things that get you after a while! 
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
A few years back, I started a consulting engagement. We took over support of all client/server programs. Get this, it was a public utility and all internal databases were in Access. Anyway, there was a large complicated program written by a non-programmer. How bad was the code?
Well, if there was more than one way to connect to a database, the "programmer" used each type. If there was more than one way to do ANYTHING, they used every method. Then, to top it off, whenever we would make a change in one section of the program (tons of SQL) then another part would break. Each time a bug would be raised, it would be a few hours for fixing, testing, and fixing the sections that should not have broke but did. We stopped answering our phones at 4pm because we wanted to go home at 5. Otherwise, we'd work into dinner time.
|
|
|
|
|
joemerchant wrote: databases were in Access
joemerchant wrote: written by a non-programmer. How bad was the code?
Who cares about the skill level of the "programmer". Being written in Access is bad enough! 
Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007
|
|
|
|
|
Dave Kreskowiak wrote: Being written in Access is bad enough!
Yes, being written in bad enough, but, for SOME (very few) instances, that may be the best option available. There is a missions orgnanization near me that sends people to various areas of the world - they have no computer support near by, so, simple apps are written in Access for them to use... if they have to, they can probably ZIP the files to a floppy and mail them back to the support size if a program arises.
Again, not preferable, but what is best for them.
Tim
|
|
|
|
|
vb front end, access back end...to clarify.
|
|
|
|
|
Live and learn! Programs like that is what made me so good at debugging. I was brought into a company to write a custom program and was later hired full time. One of my duties was to maintain and update their software. The first time I looked at the code I automatically wanted to rewrite it. I tried to fix the 350+ warning messages (most should have been errors), but doing so broke the code; that was out. Although I had discovered that touching a single line of code anywhere could break it, I soon learned how to modify it without breaking it.
Rule #1: Ye shall break down your code into individual stand-alone pieces, so that changing them has little or no effect on the rest.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
And yet not one word on cat skinning. 
|
|
|
|
|
Trying to track down a bug. Very simple little routine calls a few methods in an old COM DLL - some calculations and look-ups, nothing too special. Problem is, it only works once - if the routine is called twice in a row, it'll fail the second time around. Same inputs, same code to create the COM object, call a few methods, finish up... it just doesn't work twice.
So, i track down the code for this old DLL. VB6, which i haven't bothered to install in years, but i don't want to rebuild it anyway unless there's no way around it. Unzip the code and start browsing through it...
...and it's all forms. Except for a couple hundred lines in a .cls file for wiring up the COM interface, it's all forms. There is absolutely no UI for this damn thing, none, it exists only for some routine calculations and to retrieve a handful of numbers from an Access database... and it's all implemented by chaining 32 different forms together along with some sort of insestual communication between them.
I feel sick.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
|
|
|
|
|
Sometimes its better to just trash things and recode. You get lost in the code and take 3 times as long to get done trying to patch someone elses work. Good luck with it.
|
|
|
|
|
Sounds like something a VB programmer would do.
|
|
|
|
|
Well, how else would you do it?
VB6 is all event driven you know, all you do is place a button on a form, and when the user clicks... oh, OK, maybe I can use SendKeys..., OK, back on track... wow, this really is as easy as the book said!
|
|
|
|
|
All VB6 programmers are not like that. I've done a ton of complicated stuff with vb6. it just that novices tend towards vb6 because of it's ease of learning factor.
|
|
|
|
|
joemerchant wrote: [Reply | Email | View Thread | Get Link]
I didn't say they were. I started my consulting career on a national client server system with hundreds of users, using VB6.
It even included vertical text headings for narrow report columns! 
|
|
|
|
|
Brady Kelly wrote: joemerchant wrote:
[Reply | Email | View Thread | Get Link]
Darker than a black steer's tookus on a moonless praire night
Within you lies the power for good, use it!!!
|
|
|
|
|
Fortunately, there's a VB-coding consultant working for us, so it looks like i can push the problem off on him...
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
|
|
|
|
|
You lucky sob!
I did not think VB6 programmers should have been writing DLLs to begin with, I considered it a ridiculous idea even when I was forced to use that language for the main interface. All of my DLLs and COMs where written in C or C++.
I have yet to decide about VB.Net.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
John R. Shaw wrote: I did not think VB6 programmers should have been writing DLLs to begin with,
I do not think VB6 programmers should be doing around anything with coding.
|
|
|
|
|
That is the wave of the future – coding without understanding.
Modern MS languages are good for business – but it requires real programmers to create the frame works first. What that means is that people who understands how it all works decreases and the number of people who know how to use it increases.
Translation: If you know how it all works there are fewer jobs – If you know how to use it there are lots of jobs.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
I've just stopped smoking and drinking at the same time, I'm working on abominable VB6 and VBA code between Acess and SQL Server, so I took on a little job for extra money, and I've just received the script for the table I am to code a front end for. Field names have been changed to preserve confidentiality.
The one redeeming point is that there is no code here, I get to insert fresh, sexy, new C# code.
CREATE TABLE "dbo"."clientTable" (
"oneField" varchar(8000),
"abotherField" varchar(8000),
"andGgain" varchar(8000),
"totalOf" varchar(8000),
"21fields" varchar(8000),
"like" varchar(8000),
"this" varchar(8000),
...
...
)
GO
|
|
|
|
|
INSERT INTO clientTable VALUES("a","b","c","d"....That's going to be fun - a database that's in negative numbers for normal form. I see that they don't want Unicode either; obviously because it takes up so much space
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
"What's in a name?..." -- Bill S.
|
|
|
|
|
I surely don't need to point out that if the sum of field lengths used exceeds 8000 bytes, SQL Server will refuse to insert the row.
SQL Server 2000, anyway. SQL Server 2005 might do something different since it now supports varchar(max), but I think you actually have to use that syntax to get out-of-row varchar fields. SQL Server 2000 makes you use the slightly-differently-behaving text datatype, which confusingly can be set to be stored in the row if it's below a certain length of data.
(If you smoke and drink at the same time, aren't you in danger of putting your cigarette out?)
|
|
|
|
|
Mike Dimmick wrote:
I surely don't need to point out that if the sum of field lengths used exceeds 8000 bytes, SQL Server will refuse to insert the row.
No, but I have just received the refreshing news that we have carte blanch with the databases for our development. This is a small company, and they are actually running seven different databases on the same server!
Not for too long I suppose.
|
|
|
|
|
There is nothing wrong with running seven different databases on the same server. SQL Server is designed to do that. It depends on your definition of "database", and it is the actual size of each database and the number of users which will determine your hardware requirement, not the "number of databases" which has almost no bearing on your hardware choices.
The "not for too long" here is the lack of types in the tables. You obviously know the problem with that. Just don't go around in a small startup company telling people you need more hardware, or it will be you that's not around for too long. Tell them how to run all those databases on a cheaper server and get better performance out of it... and they'll give you a raise. Shouldn't be too much trouble to improve things, given where you're starting from.
|
|
|
|
|
In this case there is. My application had to do a cross-database query just to get user rights. This client only has one application, which uses all seven databases. I suspect they were all imported from Access at different times, without the benefit of qualified consultants like they have now.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
