Do not be over excited – my solution is not about how to open an mdb which is truly exclusively opened by others, but to cope with the situation when you can not open the mdb over the network.
For example, from time to time, Actinic crashes. And sometimes after crash, you see this message:
There was a problem with the database
Operation: Opening the table
The Microsoft Jet database engine cannot open the file ‘\\(netbios name)\Actinic v8\Sites\Site1\ActinicCatalog.mdb’. It is already opened exclusively by another user, or you need permission to view its data.
Action: Contact your Actinic reseller or Actinic Support as appropriate
The problem is caused by mdb, not Actinic specific. You may have seen something similar.
If you are sure no one else has opened the mdb file, you know Access is talking nonsense. To solve the problem, copy this file, delete the source file (you may have to operate on the local computer), move the copied file to the original place, and that’s it.
Do not ask me why this kind of problem happens, or why an duplicated file can solve the problem. I don’t know. That is one of the reason I do not like microsoft – too many times I do not know where problems come, and where they go.
Actinic gave me some trouble this morning. I was reported that Actinic crashed when uploading. My close investigation found that Actinic crashed at the point of checking catalog. No error message was shown on screen. A Catalog_version_number_date_time.dmp was generated but that meant nothing to me.
Fortunately, there were not many catalogue changes since last successful upload. The cause of problem was quickly isolated to a change of product sequence in a section. As a quick solution, I created a new section, and all products underneath by copying and pasting contents. It was not a desirable way, but what else could I do other than keeping away from Actinic?
A late investigation when I had some more relax time found that shipping supplement, handling supplement and shipping quantity of the original products causing the crash were changed to some ridiculous figures. I am used to this kind of ridiculous behaviour of Actinic, so I am not keen on finding out the further reasons.
I don’t like the way of Actinic tackle the problem. For example, if the web server set default charset as UTF-8, it will cause page rendering issue for Actinic. Especially for the pound sign. All the support knowledge from Actinic is redirecting people set the server using default chareset as ISO-8859-1. Then, my question is – why should I use ISO-8859-1 while UTF-8 has far better applicability, especially for multi-national sites?
Nevertheless, can Actinic generate an UTF-8 encoded site? The answer is yes and no.
Yes is because I have already achieved it; No is because Actinic can not make it happen for you (at least I won’t know how to control it), so you must do something outside Actinic. Here below is my detailed steps.
First, rewrite all requests to actinic generated files to index.php.
Second, create a bootscript, name it as index.php. This idea is inspired by Zend Framework. Make sure:
The bootscript should be in utf-8 encode.
The bootscript should be able to include actinic generate files according to request uri.
Third, in actinic templates, change meta tag charset to utf-8.
Last, at web server, adddefaultcharset utf-8.
The most tricky part is actinic upload its files in iso-8859-1 encoding, but bootscript is utf-8 encoded. A normal include or require by php will not render pound sign correctly. I use output buffer to hack the problem.
I have many good reasons to dislike Actinic. One of the reasons is – as growing up to an Actinic expert, one can also be an Actinic hacker. In other words, Actinic is not nicely secured by the vendor. If an Actinic user wants enhanced security, he / she will work ten times harder to close the security hole.
For example, Actinic does not have online database. Actinic keeps most of data offline, but it must have some data at server side, so itstores data in various files. This is a very doubtful approach. Of course all database software have bugs, but could Actinic file-based data do better than mysql, etc?
Another example, I recently found Actinic stops recognising coupons after an update. During diagnosis, I found discounts.fil under acatalog folder serves as data file for coupon code etc. acatalog/discounts.fil can be accessed by public by default. All promotion secrets are exposed to competitors / customers by analysing this file. Coupon codes are hashed in discounts.fil, and hashing makes all original coupon codes not recognisable. The Actinic perl script does not compare hashed customer input coupon with hashed coupon code in discounts.fil. It compares raw customer input coupon with hashed coupon code in discounts.fil (of course they will not match). This is a bug in Actinic.
I think closing security hole is out of most Actinic users’ capability. What is the point for an advanced Actinic user working so hard on Actinic?