I have split away from the sourceforge TComPort project and will maintain my own TComPort 5.0 AnsiString Version

One component I have depended on for serial port programming over the years is TComPort, originally by Dejan Crnila.

My own private fork of it is located on BitBucket now. Known issues with my last version (5.0, last touched in 2010) include that the Packet component doesn't work properly.

Some of those bugs are fixed in the latest version on SourceForge, which Brian Gochnauer has taken over maintaining. The reason for me wanting to maintain my own version is that I believe there will be two possible schools of thought out there.

Brian's thinking, and perhaps others may agree, is that a "regular String" should be used for String read/write methods. My thinking is that AnsiString should be used in both ansi and unicode Delphi versions, because serial port protocols are either binary (8 bit) or ascii (7 bit or 8 bit) and there are NO 16 bit serial port protocols that I know of.

So that means maybe you have to cast here and there to avoid implicit cast warnings, and I say, so be it.

Anyways, the other thing that I think is weird about the latest sourceforge version is that the Async read/write method appears to do things which might cause memory corruption or crashes depending on your luck.  My code used GetMem and FreeMem and allocated and copied information into distinct non-delphi-string-heap areas before they were involved in any Win32 Async API operations, to avoid unpleasantness.  That appears not to be the case anymore.  So I am publically disavowing that codebase, and leaving it to whoever wants to maintain it to maintain it.  I am no longer formally involved in that code.

I will retain sourceforge project membership so that in the event that Brian does not resume development and someone wants to repair the current UnicodeString based codebase, I can add them as a comitter. I bear no ill will to Brian, and thank him for fixing and maintaining the project on sourceforge when I had no time to do it. But I also feel that since I was publically associated with the project for many years, I need to say, I'm not happy with the code, and I think it stinks, but I'm not going to fix it either.

I'm going back to my last version, and I'll re-add any patches that seem necessary to add that have been contributed since I stopped maintaining the project actively.   Really, if I'm blaming anyone here, I'm blaming myself for not reviewing the changes as they happened to AsyncPro, for sanity and correctness. My bad.

Anyways, carry on programming serial ports with AsyncPro or with TComPort, use whatever you like, but be aware that I think there are some serious issues with the latest SourceForge version of TComPort.

A very frustrating issue with Microsoft SQL Express

Recently I had some customers complaining that they could not connect with our Delphi-powered database backed application, to their database. They were new customers and (although I did not know it) the source of their trouble is that SQL Express (like the full SQL Server product) allows you to configure incoming connection types,  those being:

• Shared Memory
• Named Pipes
• TCP/IP

The first type (Shared Memory) is fine for local connections only when the SQL server is on the same machine as the client application. Across a Windows domain, named pipes and TCP/IP are commonly used.  The problem is that SQL Express not only ships with TCP/IP and Named Pipes disabled, a condition that all of us who use it are so accustomed to that it is second nature for us to enable them,  but also, TCP/IP is misconfigured out of the box, for some versions of SQL Express.  Instead of having its "static TCP port" set to 1433 and "dynamic TCP port" option set to blank (a proper default), they are set with "static TCP port" set to blank, and "dynamic TCP port" set to zero.

Now here's where that gets really fun:

• On some client computers, using an SQL connection string that does not specify named pipes explicitly,  Named pipes will be chosen first, and everything will work.
• On some client computers on the same local area network and domain, the same SQL connection string that does not explicitly specify named pipes, TCP/IP will be chosen first, and will fail. 

Several workarounds are possible:

• Hack the connection string so it forces named pipes. This must be made configurable in your Delphi application though or you'll be stuck where I was stuck at the beginning of this blog post, with some of your clients (who are unable to use Named Pipes) also unable to use your application.  If this is a "set it and forget it hack" done in the background with no UI to select this hack on or off, this will solve one problem while creating another one, so you're just sweeping the issue "under a carpet" and making it harder for someone else in the future.
  
• Make your connection string configurable. This is flexible, but it makes configuring your application harder.
  
• Disable the misconfigured TCP/IP option completely on the server, this will make the negotiation (use named pipes? use tcp/ip? Let's check what's available and try one) go faster, but for many users Named Pipes are significantly SLOWER than working with TCP/IP.

Last but not least, is not the workaround, but the actual fix:

• Fix the TCP/IP configuration on the server, using SQL Server Configuration Manager.   Make sure that your SQL Server static port is set to 1433, and that your dynamic port option is set to blank (not configured).  

Note that in the year 2013, Microsoft still can't decide on one SQL tool to rule them all, so you've still got SQLSCM, SSMS, SSDT,  Visual Studio, and more ways to "look at your database", and no sign of one integrated tool to rule them all.    As a free product, SQL Express is amazing, and Microsoft has done great things with it, SQL Express 2012 is particularly a fantastic product.  But it has some warts, and this is one of them.   Another is that the SSMS (management studio) that comes with all SQL 2012 editions is based on the new and disgustingly slow and bloated version of visual studio shell.  I am going to stick with the old SQL 2008 R2 management studio until someone at microsoft visual studio team gets their head out of the sand.  A slow and bloated IDE shell is my favorite thing to use all day. Said no one.  Ever.

My app is in the App Store.

This app is pure Objective-C, using the remObjects Data Abstract + RemObjects SDK to  build the Delphi middle-tier server service.

RentalPointToGo uses a Made-for-iPhone (MFi) accessory called the Linea Pro from Infinite Peripherals, which is the same barcode-scanning hardware used with iphones, in the Apple retail stores.