Check out Robert Meerman's tvrenamer script which includes a fix for Unicode filenames which was proposed on this site (inside tvrenamer.pl look for the '#Unicode source names not implemented' part)
Here is the reference to the original article
There is a lot of talk on interfaces vs abstract classes and while I was working on a C# ADO.net application (with Ingres on the backend, of course) I was intrigued by the difference between the IDbconnection interface and Dbconnection abstract class. What is the difference ?
The IDbConnection interface was introduced in ADO.net 1.0 to enforce common behaviour for the providers' connection objects i.e. a standardized way of how to open a connection, how to close it etc. Of course there were a number of other interfaces introduced such as IDbCommand which at the end of the day allowed programming in a database-agnostic way.
So far so good, common behaviour is what an interface is primarily used for.
In ado.net 2.0 the DbConnection abstract-must inherit base class was introduced which implements IDbConnection; a first immediate advantage is that you get the implementation that was required by the interface's contract for free as it is implemented by the class.
Ingres incorporated automatic generated sequences, a feature that was built into other dbms products, into version 9 onwards.
So are automatic generated sequences just for convenience or are they really useful?
They have many advantages which are speed, especially when caching is enabled, scalability, and elimination of concurrency issues associated with unique key generation.
But the drawback is that they can introduce gaps in the sequence in a variety of ways :
since auto generated sequences are an object that lives in the server, on server failure
it is lost. The same is true in case of caching since it can age out of the shared pool.
Gaps can also be introduced programmatically e.g. by means of a rollback:
user A is getting a number from the sequence let's say number 8 and commits
user A is getting the next number from the sequence, number 9
user B is getting the next number from the sequence, number 10
user A rolls back and user B commits thus a gap was effectively introduced…
The line gets blurred between type systems.Traditionaly strong and static typed languages seem to find it increasingly difficult to cope with evolving requirements.(this is my opinion)
C# seems to acknowledge this fact: first came generics, then type inference (used extensively by Linq where a lot of times you cannot use explicitly typing,so you let the compiler decide) and now a new dynamic(!) type is about to be introduced.
Here is an article about it C# 4.0 goes dynamic - a step too far? which gives insight on the forthcoming C# 4.0. I do not see it as just a 'C#' article but as sign of the times and the battle between type systems
The session wide temporary tables are a very useful feature. You create the table, use it for your intermediate results and then you don't have to drop it, it's dropped automatically when the session ends.
This, except of the the ease of use that it provides has another advantage; in case of a session or system failure after a commit has been issued the table if not temporary would remain in the database after recovery.With the temporary table you have no such as issues.
An issue arises when you want to use multiple temporary tables with the same name within the same session ;e.g when the user presses a key I use a temporary table to store the product codes and print them in barcode labels. The user might want to re-print additional barcode labels so he must press the key again to initiate printing thus a 'Duplicate table' error occurs since the table has been already created. To overcome this issue I create multiple temporary tables by basing their name on the times…
Elaborating more on the IIseterr/iiseterr naming conflict by doing some research on the symbol tables inside archive library libingres.a
(a refresher on the issue:
The following entry is from the library implementation that will compile with 'iiseterr'
libingres.a:iiuflibq.o:00000cf0 T iiseterr_
libingres.a:iiuflbqL.o:00000cf0 T iiseterr
libingres.a:iiaclibq.o:000008a0 T IIpseterr
libingres.a:iiseterr.o:00000000 T IIseterr
we see that there are four implementations of iiseterr each one in a different library, thus any of the four can be used in the source code and will compile fine
In the offending implementations where the undefined reference error occurred there is no 'iiseterr' entry (as in the manual) for any library contained in libingres.a; however there is an IIseterr entry and that is why when capitalizing both i's the symbol can be found and hence compile.
(it would compile with …
New years eve.The standard procedure every year.
At the client's side the ABF application is doing some intense querying
(selects and deletes) and hangs for quite some time.
The first thing that springs in mind is that there is another query that blocks.
Looking at the sessions using IPM, the session in question was in
CS_EVENT_WAIT (BIO) state so there was no blocking.
CS_EVENT_WAIT (BIO) means the session is waiting for a message to be received from or sent to the user interface.
What is that message? the application was there waiting for something!
After investigation and doing some admin work the guilty party was found!
It was the Ingres log file!
It was set by the client to 80MB (!!) and every transaction is writing there
data for undo/rollback blocks;since the log file had not enough room the transactions were queing.
So the installation had to be brought down and the log file incremented to a few GB
and the issue was resolved.