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 '220.127.116.11' 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!
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.
A previous post on this blog showed how posting a SOAP request from the command line on Linux could be done.
Following the post about Invoke-Web-Request, I’ll show how to achieve the same task using Windows Powershell v3 CTP 1.
The first step is to build a sample SOAP request and save it on a text file, maybe called “soap.txt”. For the sake of this example I saved it on a temporary folder “C:\Temp”
Afterwards, open a powershell command prompt window and type this in:
Invoke-WebRequest http://[your web service endpoint address] -Method Post -ContentType "text/xml" -InFile C:\Temp\soap.txt -OutFile c:\Temp\soapRes.txt
The command has the following parameters:
- method: indicating the request should be sent using HTTP POST
- content type: stating the request is an XML message
- input file: the SOAP request text file
- output file: the name and path for saving the SOAP response
After execution, the resulting SOAP response is saved on the temporary folder under the name “soapresult.txt”.
The Windows Management Framework 3.0 – Community Technology Preview (CTP) has been released by Microsoft and with it comes Powershell V3.
Included on this release of powershell comes a command I’ve personally been missing for ages. A command to get or just test a given URL address. The is called:
A simple example of the command usage would be the get this blog’s home page into a single text file:
Invoke-WebRequest https://rambletech.wordpress.com/ -OutFile c:\temp\blog.txt
Another example, more complex, would be to get this blogs RSS feed and parse it:
([xml](Invoke-WebRequest https://rambletech.wordpress.com/rss).content).rss.channel.item | Select Title, Link
To download the Windows Management Framework 3.0 CTP 1 visit this address from Microsoft.
Happy programming 🙂
The evolution of information systems places more and more applications on web-based architectures. The concern with security on this type of systems has to evolve also. Any programmer familiar with Web development is a potential script kiddie. The task of corrupting, destroying or getting illicit access to data cannot be facilitated.
There is a series of guides on Microsoft Developer’s Network, on how to protect an ASP.NET application against injection attacks. The guides are pretty straightforward, giving a brief notion of the attacks and also the counter measures one can adopt to prevent them:
Even if you have already deployed applications, it’s very well worth it to spend some time analyzing them and integrating the security enhancements explained. Better safe than sorry.