Three times I tried to check the status of my order, and assumed this site must be broken because no text shows up.
Turns out I just couldn't see the text. Is it just me, or does this seem like a poor design?
Three times I tried to check the status of my order, and assumed this site must be broken because no text shows up.
Turns out I just couldn't see the text. Is it just me, or does this seem like a poor design?
I currently work at a company that some people (especially if you live on the East coast of the the United States, or in Europe) may recognize, but let's call it Initech. I currently have three different login IDs on as many domains, all of which I must use for different things on a daily basis. There is a reason for this, but it's a bit difficult to explain.
When I first started working here, I got a login on the domain INTC. All logins are numeric, by the way, in the form INTC\x123456. So, I used to use this to log in to my laptop and to connect to the various servers my team works on, mostly SQL Server instances, as well as to get into my company email and to access network storage drives.
Now, I'm a contractor (not of the highly paid variety, unfortunately) and am technically paid by Initech's corporate master, Outertech. Sometime last year, it was determined that, for unspecified administrative reasons, all Outertech contractors must have an id on the Outertech domain, SCKST. (No, I cannot explain the domain name.) So, all us contractors got new ids of the form SCKST\xi246810. All contractors had to have their laptops "migrated" to the new domain, which required them to be taken away for several hours.
The first of my colleagues whose laptops underwent this process found various side effects, including the inability to access servers, email or network storage drives, and the revocation of local administrator privileges. This did not stop the IT department from attempting to pick up other people's laptops for the same purpose, and my immediate supervisor had to order everyone not to allow this until they fixed the first laptops to the extent that my colleagues could do their jobs. The result was that by the time my laptop was migrated, the major difficulties had been solved. I still had to log in with my old INTC id to get email, although this was later solved by a second migration, changing us to a new email server.
We're still working on getting access to all the servers we work on with our SCKST ids, and must use the old ones on some servers. The network-drive-access problem was "fixed" by the advent of a VBScript that runs automatically whenever I log in with my SCKST id, and I have to enter my INTC id and password in two InputBoxes (both unmasked) so that it can map the drives with correct credentials. I understood originally that the drive ownership would eventually be changed so that this would become unnecessary. However, I am now being told that the original domain change might possibly not have been legal (no, I don't understand how that can be), which would require reverting everything to the way it was before.
The third login came about a part of a project involving some data on a server in a foreign country that is both generated and used by people here. (That entire project probably represents a WTF of its own.) It took a couple of weeks to get any kind of access to that server, and I wasn't able to get in until I realized that, instead of granting the access to my INTC\x123456 id as I had understood, they had gone ahead and created a new id, MXINTC\x123456. I am not sure if there were legitimate problems with granting access to an id from outside the domain (network admin isn't really my area of expertise), or if there was some kind of language or moron problem, but now all work on that project (which may now be cancelled anyway after several weeks of work) must be done using a third ID.
Did all of that make sense? If so, can you explain it to me?
The fire alarm system at my workplace has an odd design. When it goes off, first it plays a recorded bell sound three times. Not a proper alarm bell; actually it kind of sounds like the bell sound you get in Windows when a warning dialog pops up. Then, there's a recorded message in a calm woman's voice, which goes something like this:
The warning tone you have just heard indicates that an emergency has been reported in one or more parts of the building. When this message completes, the affected areas will be indicated. Employees in unaffected parts of the building should continue working while awaiting updates. Employees in affected parts of the building, including handicapped employees, should follow the evacuation plan.
This is repeated three or four times, to give the emergency time to get farther out of control. Only when it is completed does an actual alarm tone sound (I believe this can be set for certain areas only) along with flashing lights. In cases when it was a drill or false alarm (as it has been every time I've heard it) the alarms may continue to play audible static for as much as several hours afterward.
Also, this same system is frequently used to report cars parked illegally or with their headlights on. ("Will the owner of a gray Ford Focus with license number...")
This occurred when trying to add a primary key to an existing table in SQL Server 2008R2. It was the only error.
Hmm. Well, there are no stored procedures involved here. Or even error-handling. It's just an alter table statement.
ALTER TABLE Loans
ADD CONSTRAINT PK_Loans PRIMARY KEY (CUST_NBR, COL_TYP_CD, LOAN_NBR)
Edit: Also, it actually created the key. I probably should have checked that first, but I assumed that if it failed with an error it wouldn't have created the key. But it appears to be there and correct. So, that's weird.
Yes, Mexico. That name makes sense; it's just Mexican Initech. It's the other one that it unrelated to any name I know. Actually, since I anonymized this one without knowing what the original letters stood for, maybe it is unintentionally suckiest. (It's entirely possible that the original stands for something in Spanish, which of course I wouldn't understand.)
I found this while looking through the tables in a SQL Server database my team administers. I thought I had a reasonably good grasp of SQL, but this confuses me. Does it actually do anything? ID is the primary key, too, by the way.
ALTER TABLE [dbo].[ReferenceTable1] WITH CHECK
ADD CONSTRAINT [FK_ReferenceTable1_ReferenceTable1] FOREIGN KEY([ID])
REFERENCES [dbo].[ReferenceTable1] ([ID])
GO
ALTER TABLE [dbo].[ReferenceTable1] CHECK CONSTRAINT [FK_ReferenceTable1_ReferenceTable1]
GO
Well, Fire is what it says on the red devices mounted on the walls. The message, as you point out, does sound as if they intend to use it for multiple types of disaster if they happen. It's generic enough that you have no idea what the problem is -- bomb threat? poison gas? armed, disgruntled, former employee? Actually, shouldn't all of those require evacuating the entire building? I don't know what was going through the minds of the people who designed this.
Well, the question is whether is validates the foreign after adding a new value or before. If it validates the constraint and then decides whether to add the value, then @CoyneTheDup is correct and you could never add anything. However, since I can verify that it is possible to add data to the table, it must add the value and then check to see if the value is there. And then, potentially (for a real foreign key, at least) delete it before throwing an error message. Is that really the best way to do it?
On closer inspection, it appears it's not white on white. It's white on very light gray (RGB F4F4F4).
On closer inspection, it appears it's not white on white. It's white on very light gray (RGB F4F4F4).
Three times I tried to check the status of my order, and assumed this site must be broken because no text shows up.
Turns out I just couldn't see the text. Is it just me, or does this seem like a poor design?
Well, Fire is what it says on the red devices mounted on the walls. The message, as you point out, does sound as if they intend to use it for multiple types of disaster if they happen. It's generic enough that you have no idea what the problem is -- bomb threat? poison gas? armed, disgruntled, former employee? Actually, shouldn't all of those require evacuating the entire building? I don't know what was going through the minds of the people who designed this.
Yeah, that's actually giving you useful information immediately. They ever use it to report non-emergencies?
The fire alarm system at my workplace has an odd design. When it goes off, first it plays a recorded bell sound three times. Not a proper alarm bell; actually it kind of sounds like the bell sound you get in Windows when a warning dialog pops up. Then, there's a recorded message in a calm woman's voice, which goes something like this:
The warning tone you have just heard indicates that an emergency has been reported in one or more parts of the building. When this message completes, the affected areas will be indicated. Employees in unaffected parts of the building should continue working while awaiting updates. Employees in affected parts of the building, including handicapped employees, should follow the evacuation plan.
This is repeated three or four times, to give the emergency time to get farther out of control. Only when it is completed does an actual alarm tone sound (I believe this can be set for certain areas only) along with flashing lights. In cases when it was a drill or false alarm (as it has been every time I've heard it) the alarms may continue to play audible static for as much as several hours afterward.
Also, this same system is frequently used to report cars parked illegally or with their headlights on. ("Will the owner of a gray Ford Focus with license number...")
Hmm. Well, there are no stored procedures involved here. Or even error-handling. It's just an alter table statement.
ALTER TABLE Loans
ADD CONSTRAINT PK_Loans PRIMARY KEY (CUST_NBR, COL_TYP_CD, LOAN_NBR)
Edit: Also, it actually created the key. I probably should have checked that first, but I assumed that if it failed with an error it wouldn't have created the key. But it appears to be there and correct. So, that's weird.
This occurred when trying to add a primary key to an existing table in SQL Server 2008R2. It was the only error.
Thanks, Jamie. Yeah, it does seem like the Mexican domain doesn't trust the US ones. The two in the US sort of work together, -- you can get permissions on a INTC-domain server for a SCKST-domain id if you go through the proper morons channels, but I've not been able to do the same for the Mexican domain.
I have often thought that they don't know what they're doing. The fact that I don't know what a trust relationship is (other than what I can guess from the name) or how to set one up somehow doesn't invalidate this feeling.