Skip to main content

Posts

Transforming Ingres' legacy reports with PostScript (Part 1)

this : Plain text ASCII report (plain.jpg) into this : PostScript report (postscript.jpg) How things work at the moment: PC's with Windows OS run terminal emulators which connect to Unix/Linux servers. When the ABF application generates a report its output is dumped on disc as a plain text file which is subsequently send to a network or local printer. When local printing is required (the printer is attached locally to the PC running the emulator) then the emulator opens a direct connection to the local printer port by using special escapes (called transparent ot pass-thru printing) and then forwards the plain text file to it. In either case the file is forwarded to the printer in RAW format, bypassing any printer drivers and thus is printed as-is. The same process holds also true for reports generated by OpenRoad on Windows The disadvandes of this approach are : (1). although sent in RAW format, the interpretation lies on the printer at hand; for example some print...

Abstract class vs Interface 1-0

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. But anoth...

Auto generated sequences, the silver bullet for concurrency ?

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 effective...

C# 4.0 goes dynamic

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