|
 No, actually he's a Mac fan, and the program in question is older than spreadsheets...
|
|
|
|
|
Hey...
I resemble that remark.
Andrew
|
|
|
|
|
Real men don't need variable names! Real men use memory addresses!
To those who understand, I extend my hand.
To the doubtful I demand: Take me as I am.
Not under your command, I know where I stand.
I won't change to fit yout plan. Take me as I am.
|
|
|
|
|
I am refactoring a project that has basic unit conversion stored in a sql database along with everything else. Each time a business object gets loaded from the database, a separate call to the database is made to get the 3 units that belong to the business object.
When is the last time any of these natural conversion has changed? Are they suddenly going to change the amount of milligrams in a gram, or pounds in a ton?
If there were any conversions that were irregular like grams in a case or something like that, I understand, but for the natural conversions? The worst part is this database is almost always called over a VPN connection, so bandwidth is critical. The previous programmer could have at least cached the data on the client side or something...
|
|
|
|
|
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
|
Netblue wrote: The previous programmer could have at least cached the data on the client side or something...
But that would make sense!
|
|
|
|
|
Do they happen to be storing the current time in the database as well? 
|
|
|
|
|
I think there is a webservice call for that one...
|
|
|
|
|
lmao
To those who understand, I extend my hand.
To the doubtful I demand: Take me as I am.
Not under your command, I know where I stand.
I won't change to fit yout plan. Take me as I am.
|
|
|
|
|
How many ounces are in a pint?
|
|
|
|
|
IF your lucky 20, if your in the states typically 14, unless your local pub has the good glasses that allow a full 16 with 2 inches of head.
|
|
|
|
|
You only get two inches of head? 
|
|
|
|
|
Netblue wrote: The previous programmer could have at least cached the data on the client side or something...
That would have been nice.
Netblue wrote: The worst part is this database is almost always called over a VPN connection, so bandwidth is critical.
Is it possible to make any changes to that or are you stuck with it?
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Paul Conrad wrote: Is it possible to make any changes to that or are you stuck with it?
There are 8 locations connecting to a central site, VPN over the net. A better way to do it would be SQL replication, but the locations can't support a server of their own, at least not right now.
|
|
|
|
|
That's a bummer.
Netblue wrote: A better way to do it would be SQL replication
Sure, but then that could open up a new can of worms when trying to manage all those replications and synchronize them, if you needed to. Maybe not, because I don't know what kind of data flow or volume you are dealing with.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Just a second here:
What if the application was being used in the UK, then used in the US or Australia? Conversions do vary... 
(though maybe a localised lookup table, and, sure - why not - a little caching or even dare I suggest hardcoding might help perf a little )
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
And then somebody suddently alters some conversions in the database and all clients with the cached data will have an update problem until the next session. To avoid this, we now need a way to let the clients know that the cached data is not up to date. And then.... 
Honestly, this is exactly what blind obedience to 'good practices' leads to. Of course it's a good idea to make the database work for its money, but this should nonetheless have been avoided. Quick and dirty solutions to correct this lead to still more quick and dirty patches. Recommended practices can not replace thinking.
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'.
I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
|
|
|
|
|
When I joined my current company about three years ago, I was given the task of maintaining the company's business critical order processing system. This is written as an Access front end to a SQL Server back end, and was written by a contractor who had left at the end of his contract with a large amount of the company's money in his bank account!
Some investigation after my first week or two lead me to discover the following horrors:
There was not a single error trapping routine in the whole front end - if something fell over, the standard error message was "an error occurred in the click event of btn....."
Each routine that inserted a record was written as a Sub, rather than a function that returned a success/failure value.
Every user on the database was assigned DBO permissions!
There was absolutely no referential integrity defined in the database.
There was no transaction processing in the system - if someting fell over part way through (as it often did), updates/inserts/deletes had to be rolled back manually using Enterprise manager.
An example of his coding style is shown here - it shows how he retrieved a single record using its primary key:
Set rstMain = New ADODB.Recordset
Set cmd = New ADODB.Command
cmd.ActiveConnection = CurrentProject.Connection
cmd.CommandText = "spSELocationForSageImport"
Set prm = cmd.CreateParameter("@LocationCode", adVarChar, adParamInput, 20, "Sage")
cmd.Parameters.Append prm
cmd.CommandType = adCmdStoredProc
rstMain.Open cmd, , adOpenDynamic, adLockOptimistic, adCmdStoredProc
With rstMain
Do While Not .EOF
strLocation = ![Location]
.MoveNext
Loop
End With
Set rstMain = Nothing
Maybe I'm missing something, but do you need to loop though a dataset that can only contain one record?
His date handling was also a bit esoteric:
txtDateCreated = Month(Now()) & "/" & Day(Now()) & "/" & Year(Now())
I recently had occasion to rewrite some of his code that applied changes from an external system to the database. His code took two or more hours to run and slowed the system so much it was unusable (meaning I usually had to do unpaid overtime to apply the data out of hours). One of the lovely bits of code he wrote looped through a data set of 7000+ records, taking a value from each record and using this as a parameter in a stored procedure that retrieved a related value from a lookup table. Changing the source query of the main dataset to join it to the lookup table and return the value directly removed 7000+ executions of the stored procedure.
Tweaking the query, adding an index and cleaning up his code reduced the run time to approximately 3 minutes!
====================================
Transvestites - Roberts in Disguise!
====================================
|
|
|
|
|
I have the feeling that the guy in question once read a chapter on ADO and has abused the same example ever since ....
I'm largely language agnostic
After a while they all bug me 
|
|
|
|
|
Hehe, I basically suggested the same 
|
|
|
|
|
Chris Quinn wrote: Maybe I'm missing something, but do you need to loop though a dataset that can only contain one record?
Because it returns a list with 0 or more values. Or maybe he only knew that single pattern 
|
|
|
|
|
As the others have said, it does look like he found some example and kept using it over and over. Pretty much any VBA coding in Access is a strong candidate for being a coding horror.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
I don't agree - it's not the tool you use - it's the tool that uses it!
====================================
Transvestites - Roberts in Disguise!
====================================
|
|
|
|
|
True. Access can be alright when used correctly.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
