Reality is such a pesky thing. Better to ignore it and forge onward!
Posts made by Volcanon
-
RE: But We HAVE to Deploy It
-
RE: Stupid Salesclerk
Not not mention that nowadays as long as the order of the wires is the same on each end it'll usually work.
-
RE: Windows Server 8
No matter what folks say, I highly doubt Microsoft will stop making their GUI a hugely powerful part of the OS.
I'm sure everyone's wanted a powerful CLI in windows before, but the GUI is what got Windows Server its market share.
-
RE: More Java, sorry
Secure computer environment? I'm fucking confused.
Java has done nothing but introduce security holes into my network.
Additionally some versions have bugs that cause a PC to hang when you try to GPO an update for Java. Really great software. Gotta rank it up there with Adobe Flash in terms of shit-baggery. -
RE: The long way to India
Join the club. Where I work the only option we have for internet is T1 service. 1.5Mbps down/up per line and each line costs 300 bucks a month. I pay 35 bucks a month at my apt for 25 down and 2 up. Whenever I download any ISOs or anything for work, I just download them at home and use a flash drive or external HD for transfer.
The upside is that I live like 5-10 minutes from work, including time taken to walk to my car, etc. -
RE: One-liner
It's just a misnamed event.
When the object SelectMachine's text is changed SelectMachine_Click is run. No clicking necessary.
However if there is a seperate method for clicking and text changing and he's swapped them around, god help us all when someone clicks on something or changes text. -
RE: We won't need to know
Sounds more like a corporate pissing match. Time to find out who has the most pull, regardless of who is right!
-
RE: Please god tell me I've been doing this wrong forever.
As said before, you may as well just use Convert.ToInt32 instead of converting it to a string and then back to an integer. Saves you a little conversion, but the end result is the same.
-
RE: I'm no DBA....
Yeah I tend to follow arbour's guidelines. If you don't think a char(1000) field with an average of 50-100 characters in it is wrong, one of us must be very confused cause I think it's very wrong.lol
-
RE: I'm no DBA....
Some more shenanigans from the same database. I have been finding some more and piling them up as time goes on, but here are some gems:
We see a lot of disk and CPU bottlenecking at times of high queries and usage on our production server. I was curious as to why and so I went and looked at the RFLog table again to start. (the table mentioned at the beginning) I had not yet examined datatypes and the first thing I see is absolutely horrific. Two of the three textfields are Char(30). These are populated by an IP address, and a name. Most of these values are 5-15 in size.(maybe they wanted to be IPv6 compatible?:P)
Farther down, it gets worse. The log field where it describes the error message, a char(200) field. Most messages are less than 50 characters. No message is longer than 100. I begin looking at all the other tables, suspecting foul play, I find that there is no varchar usage at all. Char is used for almost all numbers, big and small, and for every text field. There are a few char(1000) fields. In one table, the char(1000) field is 95% no more than 10 characters.If I had to guess as to why it's this way, I would guess that it's because the way formatting is done on the front end, they likely couldn't figure out how to pad and just decided to pad with the database. No joke.
-
RE: I'm no DBA....
They don't use date or time data types. The data type of the timelog field is an integer. The system counts itself. It has it's own date and time tracking mechanism. I'm sure the code for it would fall under the category of "crappily reinventing the wheel"
-
RE: I'm no DBA....
@tiller said:
You do not have 3 different primary keys(There can by definition only be one primary key, hence primary).
You have one composit primary key with 3 fields. So 2 questions: Why do you have a primary key at all. Do you really need it? I know some dbas are going to hate me for saying this, but I think that logging is one of the very very few cases where you don't have to define a primary key.
And what the hell is up with date and time beeing 2 different fields, instead of just a datetime(Or what your database calls that type). That is a true wtf which indicate that the database is really fucked up. So looking forward to more entries about that database in the future :}
Believe it or not, I did suggest we just do away with PKs in that table because I agree, though it is not in the best practices book, I don't think we need a PK for that table at all. It is not edited, simply added to. They didn't want to do that however, because, as I said, if they did away with key constraints, the log would be spammed by duplicate errors.The reason why date and time are seperate fields, I am told, is because of the programming language used to build our front end. They call it Clarion. I have never heard of it, but wiki does have some information on it. Apparently in Clarion your dates and times must be in a number format. It would also likely be more complex to have a date-time field, and I think we're about at our limit for their capability of complexity;)
Yes there are many more WTF's, and some screencaps of some of our tables might be in order, just for the lulz:) -
RE: I'm no DBA....
@RaspenJho said:
You can't have two duplicate email addresses at the same time. Emails going to that address always route to the same place.
And I have a feeling that you don't hate to tell me this at all :)
You misunderstood him.
Suppose you have a customer contact, John Smith, jsmith@company.com. You have a database entry for this person. Later that year they are replaced by Jane Smith, and they give her his old email address. For historical purposes you'd want two seperate entries, John smith and Jane smith, both with the same email address. If the email address was the only PK, you'd run into trouble. This is a databse design issue, not so much an email issue.
This is also a situation where an email address may not necessarily be a unique natural key. Though in most cases, you would probably be safe assuming that email addresses are unique. -
RE: I'm no DBA....
@KattMan said:
Where is thier unique ID field?
They don't use them, anywhere. I have scoured the database for some kind of ID key usage, but there is none. All keys are natural keys. It is quite horrific.
-
RE: I'm no DBA....
@MeesterTurner said:
@Volcanon said:
If ever get access to their sourcecode, you will see probably a week's worth of articles by me.
My company is also looking at buying the source to the only piece of software that isn't in-house developed. I think I'll be spending a lot of time posting here when we get it too...
You have no idea....
In our production front end... you cannot sort by column. The scrollbars do not work correctly and when you do use them, it slides your mouse slightly to the left. Any screen you look at queries multiple tables and pulls in all of the data for all of the fields, whether or not you wanted to see it all or wait for it to load. Reports randomly break and the ones that do work often randomly leave out information.The coding for these bugs, which have existed for as long as we've used the software(about 4 years no), is probably hilarious.
-
RE: I'm no DBA....
I believe the issue they were trying to resolve was spamming of the log and to do that they used key constraints.
This is likely why they didn't want to remove time as a key constraint. The table has only 6 rows and 3 of them are PKs... maybe if we make the error itself a PK as well and thus prevent duplicate errors but allow multiple errors to be thrown at once?:)
-
RE: I'm no DBA....
@morbiuswilters said:
@Volcanon said:
This a good idea or a bad one?
It's a bad idea. It actively prevents simultaneous (or even near-simultaneous) errors from being logged, right? That's a major failure, no matter what other reasons they might have had for using those PKs.
@Volcanon said:
Maybe one day we'll have a real production system.....
Bad performance? Mysterious bugs? Inept developers? Sounds like you already have one.
We were actually on a support call with my boss and several of their developers when the lady in charge mentioned the PKs. I immediately suggested we remove the time as a PK and use another field. She essentially ignored me and said "I added a routine to add the time+1 for this particular error so that it will get logged."
Some other funnies regarding their support.
They quoted us at 6 hours for our newest palm app, which is supposed to allow us to do batch labeling. They then gave us an app that they made for another customer of theirs. Obviously it didn't work at all. We then go through probably 20 different itterations of software before we get a somewhat usable program. Now it works and the final result: 65 hours. They want want 9 grand for this program that they originally said would cost us about 800 bucks.I think they charged us about 20 grand this year for fixes, in addition to another 20+ grand that we pay for support. I believe we ended up paying the 20 grand for support plus another 2 grand for fixes. My boss refuses to pay them to fix things that break, they disagree with him on that.
These issues are just the tip of the iceberg. If ever get access to their sourcecode, you will see probably a week's worth of articles by me. We're currently look at a full ERP system to replace our seperate attendance, payroll, accounting, and production systems. I imagine there will be more hilarity to ensue.
-
I'm no DBA....
We recently had an issue with a certain error not being logged in our production database. A quick call to our vendor and a look at the database reveals why - the log table that this event was supposed to be logged to has three primary keys, the device name, the time, and the date. This means that a PDC can't log more than one event every couple seconds (due to the way time and dates are handled in the database, they end up being ridiculous numbers, today's date, for example, is 76324, and the time is probably something like 2 million). The result of this is that some errors that occur don't get logged, making troubleshooting more difficult.
I'm not quite sure why the hell they did this, any professional DBA's out there care to comment? This a good idea or a bad one?
A recent adventure they caused is definitely not a good idea, one of their developers, while trying to get some extra logging into one of our new Palm apps, accidentally made it log too much. In one month the table had grown from 300k records to 4.5 million records. Our largest table is 12 million records. Due to software inefficiencies, that table being so large made certain parts of our front end nearly unusable.
Maybe one day we'll have a real production system.....