The reason this is annoying is because I backup my source code by copying the entire folder and its subfolders, and these gigantic TDS files are in those folders.

Could you make newer versions of the compiler put the TDS files in the same folder as the OBJ files? That way we can easily backup our source code without these temporary files wasting our time or space.

The reason this is annoying is because I backup my source code by copying the entire folder and its subfolders, and these gigantic TDS files are in those folders.

Could you make newer versions of the compiler put the TDS files in the same folder as the OBJ files?

On Tiburon’s side, in order to have a smooth upgrade path, imho, what would be a nice thing would be a property Encoding: TEncoding read… write… ; on TDataSet and on TField descendants. If Encoding is nil in TDataSet then it will grab the value from a global/project variable. If Encoding is nil in TField then it will take the value from TDataSet’s one. This (combined with DBVersion indicator) will allow a gradual change in DB, thus keeping the code base in a stable state. Of course, ‘Encoding’ applies (AFAIS now) at strings and blobs/memos only… Also if we’ll have in the TDataSet component’s right-click popup menu a choice saying ‘Set all the fields to enconding’ won’t hurt of course…

David?

A possible workaround: Create an F1U field as Unicode. Write two triggers that translate WIN1253 to Unicode from F1 to F1U on change, and vise versa: from F1U to F1. Leave the current application as is (assuming that it will not barf on the F1U field anywhere). In the Tiburon version, change all F1 references to use the F1U field.

This way, the old and the new can coexist to a certain degree. On the other hand - it is advisable to write your client contracts in such a way that they are obliged to upgrade to the latest production version within reasonable time. If you don’t, you will end up with a version compatibility nightmare.

Write "Grace period" functions that warn the user that his application will cease to function withing 30 days unless he upgrades to the latest version. Make sure you can override such a function per user if you have users with unreasonable incompetence levels.

Can I put a problem for you? If you solve it, I promise that I’ll try to grab for you the best virtual full-colored shirt to be found arround…

The problem:
We have 100 clients which use a central DB (charset WIN1253 - Greek) through a Delphi fat client. In the above DB we have (let’s say) a table T1 with two fields F1 and F2. We want to convert the data from F1 to Unicode (eg. it’s a name of a person etc.) and F2 to leave ‘as is’ (let’s say that inside we have RTF data). We have in our application in 300 places F1.AsString and F2.AsString and in 200 places F1.Value and F2.Value where in those F1 and F2 are parameters passed as TField or FindField(’F1′).Value, hence will be a variant which will be converted from/to string.

Quiz:
How we upgrade the above system to Tiburon without any problems, knowing that from 100 clients 10 will upgrade immediately, 20 at different dates in the next month, 30 /might/ update, 25 are in vacantion/sick etc. and will open their client after a prolonged period of time and 15 will "never" upgrade?