Archive for June, 2006

10 billion flies can’t be wrong…

Tuesday, June 27th, 2006

PayPal claims that they have “Now Over 100 million accounts”. Here you will learn why…

The story begins in September, 2003.

I’ve lived in Hungary and I needed to pay using PayPal. I thought it would be easy – I was wrong.
I started to create an account, then I faced that Hungary is not a selectible country. I got used to solve problems in my life quickly, so I selected Germany then.
Of course, when I tried to add my Hungarian credit card, then it complained about it.
Then I gave up, abandoned this account, and created a “fully Germany” account after asking my sister who lives in Germany to provide me an extra card with her name and address. I used that with no problems over the years.

Then I heard that around middle of 2005, PayPal started to provide services for Hungary also – even though send only, but I could’ve lived with that.
I didn’t bother too much as I could use my Germany account once a year when I needed it for eBay or so, though most of the time I could manage the money issue with a mail order (to USA) or money transfer (IBAN) for Europe.

In May 2006, I could’ve had an “opportunity” to pay with PayPal. As my Germany card expired and Hungary was added I thought that I create a Hungarian account. And again, I thought it would be easy. And again, I was – extremely – wrong.
– To my suprise, my abandoned account still existed…
– To my greater suprise, I could change everything, except the “Country” field…
– To my greatest suprise, I realized that I cannot DELETE my account unless I verify it. As anyone with IQ above 20 can see, I would not be able to verify an account as I cannot provide a Hungarian credit card which would PayPal accept as “Germany”. Nor I am willing to do that just to cancel it… 

Then I contacted PayPal to resolve my issue, but after about corresponding with them for two weeks on this simple issue (change country or finally just delete that f***ing account) they always ended up wanting me to verify my account. So I must assume all those people I corresponded with, must have IQ less then 20. (Eg. they are totally brainless morons – if IQ<20 is not clearly telling you that.)

Of course I could’ve just created another account (with any other email address, which would be not a problem) – but I got a bit “frightened” about how would PayPal handle a *real issue* when they fail to do so with this simple case, and meanwhile I’ve settled the payment without using paypal. The seller really enjoyed my forwarded conversation with them. He also agreed that they’re a bunch of idiots.

Here are the conversation in full details (for others to “enjoy” too):
0-fg-webform.txt – My 1st complaint via webform
1-pp-16-1827.txt – Their 1st answer
2-fg-16-1855.txt – Me, 2nd.
3-pp-17-1420.txt – PayPal 2nd
4-fg-17-2201.txt – Me, 3rd
5-pp-21-0201.txt – Their “last” answer. I gave up currently, but I’ll try to supply invalid creditcard and other methods to violate TOS what might be resulting in cancellation of my account…

Some days later, I got a “satisfaction survey” link – in full German language (no any option to change it), but I’ve managed to get past on it, one can imagine how they scored…

So, now you can understand why they have over 100 million accounts…

By the way, Hungary is part of the European Community since May 1. 2004, as someone else mentioned it in another mail to PayPal, not “being satisfied” that he cannot use a Hungarian PayPal account to accept money…

Here are some additional notes from on this topic.

As as read today, AOL account owners have similar problems :-]


Feel free to refer to or include the above at any medium, with a reference to the original (this) article.

Btrieve (Pervasive SQL) and long filenames on NetWare

Saturday, June 24th, 2006

I recently faced the problem that Btrieve (or Pervasive SQL) cannot create (and handle) long filename (non 8+3) on NetWare volumes mounted after Btrieve loaded.

It needed some time to find out and verify that this is the real cause, and also working out a fix that Btrieve would be loaded after all volume mounted.
Putting bstart at the very beginnig of the autoexec.ncf (after server name and internal ipx) could work for cases where the server is “old”, eg. 3.12 or 4.11-non Small Business, however, on a Small Business and from 5.x, after mounting sys, DS autoloads, which autoloads NLS (Licensing Services), which autoloads Btrieve. Other volume mounts likely to finish after these happened. TCPIP.NLM also relies on Btrieve so as ArcServe for example.

After a little while, I realized that the simplest solution is just put a bstop and a bstart into autoexec.ncf – somewhere after volumes are all mounted – optionally with some delay, such as:

   mount all
   ?# - this will wait for 10 seconds (unless default overridden)
   ?# - another 10 seconds

Btrieve will not unload completely, but the essential files will, then after a bstart, all mounted volumes will be recognized and used by Btrieve as “long-filename capable” (given that OS2 or LONG name space added of course).