Having an Oracle database with a given table storing long strings as binary data types (BLOB/CLOB), one might need to perform manual updates on those columns:
update myTable set lobColumn='Some String Value' where somekey=somecriteria;
The following error might occur while performing the direct update on that column:
ORA-01704: string literal too long
Cause: The string literal is longer than 4000 characters.
Action: Use a string literal of at most 4000 characters. Longer values may only be entered using bind variables.
The origin of the error is that the string value passed is indeed over 4000 characters long. A simple workaround script that works like a charm is:
vString := 'Some very long string value'
update myTable set lobColumn=vString where somekey=somecriteria;
Don’t forget to replace “myTable” and “lobColumn” with your table and column.
Given the task of migrating a Sharepoint 2010 web application, from quality assurance to the live environment, our team backed up the site using the Powershell Cmdlet “Backup-SPSite”. Afterwards, we copied the backup file to the live farm and executed the “Restore-SPSite” Cmdlet. The following error message appeared:
Restore-SPSite : Your backup is from a different version of Microsoft SharePoint Foundation and cannot be restored to a server running the current version. The backup file should be restored to a server with version '126.96.36.199' or later.
After comparing the patch level on both farms, a missing security update was identified on the live farm. Having multiple applications hosted on the farm, the update roll-out was not an option.
So one of my colleagues found that the old school “stsadm” command allows the backup and restore of Sharepoint sites without checking the build number on the farm.
The solution was to use the following commands:
- On the Q&A server, open a command prompt and enter “cd C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN>”
- Execute the following command:
STSADM.EXE -o backup -url http://server/site -filename backup.dat
- Copy the resulting file to the live farm.
- On the live farm, open a command prompt and enter “cd C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN>”
- Execute the following command:
STSADM.EXE -o restore -url http://server/site -filename backup.dat -overwrite
- Open the desired URL and check for your site’s correct update.
Thanks to Nelson!
Installing a server instance of Microsoft’s Sharepoint 2010 Server, I faced the following problem: the server had no Internet access and Sharepoint’s setup relies on downloading the pre-requisites from Microsoft, through the public Web.
The solution is to download the pre-requisites software and copy them to the server. Here’s a list for future reference:
Besides the pre~requisites don’t forget, if you’re deploying a new server on a farm, to download and install:
- Windows language packs
- Sharepoint language (Foundation and Server)
- Security Updates
Having a custom developed Web Service hosted on Windows 2008 Server, after some fine tuning on the system, the service started to respond with a SOAP fault stating “Requested registry access is not allowed”.
The origin of the error was the attempt the service made to write on the Event Log.
One of the changes we had made to the application was the application pool identity. It was running on Classic mode with a given domain account and we re-configured it to run on integrated mode with the application pool identity.
To grant rights to a given user account for writing on the Event Log, you should perform the steps to edit the registry described here:
- Find key “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog”
- Right-click and choose “Permissions”.
- Put in the desired account
The catch is that the application pool is running with the Application Pool Identity Account. This is a Windows user account called “IIS APPPOOL\AppPoolName”, which is created when the Application Pool is created, where AppPoolName is the name of the Application Pool.
On the permission dialog, search the local host for the “IIS APPPOOL\AppPoolName” replacing “AppPoolName” for your custom given name.
After that, the Web service worked fine.
Chrome is a really good browser and one of its highlights is the speed on starting up and rendering Web pages.
Having it installed on the corporate office workstation, I noticed it was much slower and taking forever to load some really simple stuff.
After some research on Google, I found and tested successfully the following scenario:
- The proxy server is automatically configured through network policies.
- Configuring the proxy server directly, without automatic configuration, restores Chrome to its full speed.
For people using Mac and Linux its a pretty straightforward operation. For Windows users such as myself, one might be trapped by security policies that don’t allow changes to proxy configuration by domain accounts.
A workaround for this security policy inhibition is, having local administration rights, to edit the registry:
- Start/Run the “Regedit” tool
- Find the key “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings”
- Set the ProxyEnable entry to “1”
- Create a “ProxyServer” String entry and set it to «your proxy server address»:«port used» (ex: 10.0.211.11:8080)
- Finally, go to your browser’s LAN settings and disable automatic configuration
Restart Chrome and it should be flying again 🙂
Assigned with the task of updating a console application from .NET 2.0 to 4.0 and perform some enhancements, I migrated the solution under source control, from Visual Studio 2008 to 2010.
When trying to run the solution in debug mode for a given set of command line arguments, the following message appeared:
The current project settings specify that the project will be debugged with specific security permissions. In this mode, command line arguments will not be passed to the executable. Do you want to continue debugging anyway?
Since the whole purpose was to test the arguments, I cancelled the pending debug execution. After a short research, the solution is to just disable the “ClickOnce” option.
Assigned with the task of updating a .NET application to use the most recent framework (4.0) and Oracle driver (ODP.NET) I was confronted with the following error at runtime:
Could not load file or assembly Oracle.DataAccess Error
After reading Mark Williams answer on this thread, the solution was to simply to check what scenario my development machine fitted on:
- 32-bit ODP.NET installed on 64-bit o/s
- .NET application compiled with either “Any CPU” or “x64” set for the “Platform target”
- The application is then deployed to the 64-bit host with the 32-bit ODP.NET installed
- The application executes as a 64-bit application but tries to load the 32-bit ODP.NET, thus the exception
My scenario was none of the above, but an additional one:
- 64-bit ODP.NET with the “Any CPU” set for the “Platform target”.
As soon as I selected “x64” for the platform target, all performed successfully:
HTH you all.