You're right about them being loopy pills. A friend of mine ended up addicted to them (along with a number of other painkillers and anti suppressants) for years. The withdrawals were unpleasant to say the least. If you haven't looked into its principal use then I suggest you do, as hopefully there would be some less potent medication that would be suitable for your mum... fingers crossed anyway.

We're still using it, although after the best part of a year of inexplicable crashes and corruption errors we're in the process of replacing our main database for another one. There's still loads of cheap crappy databases floating about though (some of which are now also developing random bugs even though the source code hasn't changed in months.) I'd agree with others that it has its place, but its place isn't in a corporate environment. As a rule, it only ever seems to be used in a multi-user setting out of either necessity or cost. Avoid in all other cases.

A favourite trick of mine is - for example - to give the cashier £70 for a bill of £66.32, then after they've entered the £70 into the till tell them "Oh I've got the 32p if you want it." Then wait for their brains to explode...

This isn't far off what one of the departments I support does. :doh:

The one that sticks in my mind is an email from a recruiter stating that the client wanted somebody with five years .net development experience... ...in 2002.

I'm having trouble getting an Access plugin working for all users. The setup application installs/registers the dll and associated tlb file absolutely fine (installed for all users) and my VBA code (below) also works successfully when logged in as an administrator, but attempting to use it under a non-privileged user account fails here:

Private Sub Form_Load()
With COMAddIns("MyPlugIn.Connect")
' Make sure the COM add-in is loaded.
.Connect = True ' <---- Fails here

    ' Hook up the desired objects.
    .Object.HookupControls cmdUploadImage
End With

End Sub

The returned error is: This add-in is installed for all users on this computer and can only be connected or disconnected by an administrator. Is there any way to prevent this? Some additional information: - The dll/tbl and setup application are all created in C# (.net 3.5) - The target machine is virtualised, so any user could potentially log into it (thus installing the plugin for the active user isn't an option... though if there's a way to silently install the file in a user login script that might work?) Thanks in advance... though I'm more hopeful than expectant! :(

Have you been to the media with this?! :wtf:

No, in order to do that it also copies the entire table into a worksheet, then does a lookup from there! (I can't be bothered to even look into what that's used for.)

This one's just plain mad. Quick pseudocode: Sub DeleteRecord 1) Copy entire database table into Variant array 2) DROP TABLE 3) CREATE TABLE 4) Write everything back apart from the record we don't need

...is there anything more frustrating in a developer's life? For the past week or so I've been modifying a third party's Excel VBA to run against SQL Server rather than Access and constantly find myself asking "why the #### have you done this?!" It's a good thing the author isn't in the same office else I may have ended up swinging at him. :mad:

Thanks... I'll hopefully take a look again tomorrow but the same setup (as far as I can tell) works perfectly in my test environment. Typical... :)

If anybody can offer some advice on a problem with Integration Services I have I'll be eternally grateful. I'm all out of ideas and getting frustrated to say the least! :mad: 1. I have a SQL job that runs an Integration Services package 2. The job is set up to run using a proxy account. 3. When then job is run it fails with the following error: Could not load package because of error 0xC0014062. Description: The LoadFromSQLServer method has encountered OLE DB error code 0x80004005 (Login timeout expired). The SQL statement that was issued has failed. 4. The package name is correct. 5. I’ve double-checked that the password used for the proxy account is correct. 6. I am able to connect to Integration Services using the same account as the proxy and run the job directly from there.

I typically get 3-4 unsolicited emails from recruiters weekly, most of which go in the bin without a second glance. Today's one did catch my eye though: My Client is looking for a VB6 developer on a 3 month contract. The day rate for the contract is around £115 per day (absolute max!) Skills Required: o Visual Basic 6 o SQL Server 2000, 2005 o Classic ASP o Java Script o C# (desirable) o ASP.Net (desirable) o ASP.net MVC (desirable) o Java (desirable) I was tempted to reply and ask how many years ago he sent the email...

I recall one vacancy specifying "10 years .net experience" as mandatory. I also recall that this was around 2006... :doh: