Proxy Cache Problem

Several days ago, we have a pre-deployment simulation problem with a 3rd party tool called FckEditor. We tried to upgrade the version of the tool to higher version.
Actually in the development, we already noticed that this tool is using cache for performance when loading the files (scripts, css files, etc), but since our local will not go to proxy, we didn't have issues with this.
But after we deployed this to the staging environment, we encountered problems that sometimes it was working and sometimes it wouldn't. I tried to remove the cache-control from the header, destroy the app domain by saving the web.config, and in the end, even IIS Reset was not working.
Finally I realized that there's a proxy cache since we're using proxy servers to access the server.
In that time, I could really simulate 3 different behaviours using 3 different proxy servers when loading the tools :(
After that, we're trying hard to find out how can we reset the proxy cache, since we don't have the ability to do this, and we also can not reset the server.
But in the end, the solution is quite simple, instead of deploying the tools in the existing version folder, just deploy the tools in a new folder and then change the configuration folder settings for the tool, so we don't have to worry anymore since the cache will be retrieved from the new folder :)

PS : this idea popped out in my mind when my friend showed me that he has no problem upgrading the FckEditor at his local, he was renaming the folder name between FckEditor versions to show that it was working.

ASP.Net - Export to Excel - Unicode characters are not being displayed correctly

I found this problem when exporting datagrid to excel using .Net Response object.
Quite strange actually, we have no problem in our local (WinXP), but when we deploy to the Server (Win2K), the excel result is not displaying the unicode characters correctly.
It can work after we tried to open the excel result using notepad and then saved it with unicode encoding, notice that previously when we first open the document in excel, the font is Arial, but after saving the file with the encoding, it is using Arial Unicode MS.
After several hours, testing this and that, in the end i found an article for exporting datagrid to excel in CodeProject.
And the reply post in the link just resolved my problem.

Illustration :
When exporting the datagrid to excel, actually all of the things are still in html elements (can try to open the excel file using notepad / text editor). So the content will be <table><tr>.....</tr></table>.

I thought that this encoding problem can be resolved by trying to modify the charset and contentencoding in the response object. But i was wrong :(
From the reply post above, you can see that actually it is very simple thing, just add a head element with

<meta http-equiv=Content-Type content="text/html; charset=utf-8">

before rendering the datagrid.
This way, the output can be intepreted correctly, and the unicode can be displayed correctly.

Korean (Unicode) ASP Application Migration

These are the things that my Team discovered when we did the migration for Korean Application from Korean Server Based System to English Server:
1. Database objects
If the tables are already using nvarchar / nchar as the field type, there should not be a problem.
But if the fields which contain korean characters are using varchar / char with korean collation, we will need to modify the field type into nvarchar / nchar.
And after changing the field type, all insert / update to these fields will have to have 'N' before the string, for example : N'This is the string'
The modification can be :
- in the code
- in the stored procedures (parameters)
2. Language Packs
The server may need to be installed with the korean language packs
3. Sending Email
The application has a tool to send out emails. There's a feature to encode the from name, subject, and body using certain charset, euc-kr is a standard charset that we are using for Korean Application.
4. ASP Application
To display the information correctly in the korean characters, we may need to set the <%@ CODEPAGE=949 %> in the top of the page.
Previously we're using the Session.CodePage=949 but still don't know why it's not working after we move the application to our server, but we tried using Session.CodePage=CP949 and it worked.
Because CODEPAGE=949 is documented in the msdn articles and Session.CodePage=CP949 is not, we decided to just use the CODEPAGE.

Introduction & Background

Hi All,

Actually I want to do this quite a long time ago, because in these years being as a developer, I experienced a lot of difficulties and dead ends that I could not resolve.
But in the end, many thanks to the internet and all the people who have submitted their experiences to the web, I was able to resolve many of them :)
And also many thanks to the people who have helped and guided me in these years, you are all the greatest teachers that i have :D
So hopefully, my posts will be able to help you all, so you don't have to waste hours late in the office like me before :P

A little bit of my background :
I'm actually not from a technical background degree, in fact, i'm from economic degree, but don't ask me anything about it :P
After i finished the final university exam, i worked as a technical support for a several monts, assemblying and disassemblying computer parts, hhhmm... wonder where this part should be :P
After the graduation, got interviewed by several IT companies, kind of hard coz' i'm not from IT background, but in the end, I joined a software house company. They are handling Health Information System. I joined the company in a quite good timing, because they were migrating the previous application from FoxPro to .Net (VB.Net). So this really built my base for .Net knowledges and I have a lot tutors and great colleagues along the way there :)
After 2 years, i moved on to another company, this time it is a mining company and quite isolated, but in the environment, i found a lot of new things here, from doing Macro Excel Reporting, COM+, C#, Web Services, Window Services, Console Applications, Replication Engine, Batch Engine, Scheduler Engine, .Net Interopability with COM+, Enterprise Services, BizTalk Engine, Windows Server 2003, etc. But in the end, it is the great people there who gave and share the knowledges to me :)
After finished my contract, I decided to try my luck abroad and now I'm in a technology company and handling their marketing site. Quite interesting for me, since the application is being used accross the asia pacific japan region, so a lot of customers to handle and to communicate with along the way :)