Re: Using a preprocessor for constants in SQL

> If you change the length of fields between testing and production, it
> would invalidate your boundary testing! What if there is a bug in
> your code that presents itself when a field is 200 characters, but
> not when it is 50 characters long? There is no difference in disk
> usage with the example you gave, so I can see no reason to have
> different lengths for varchar fields between test and prod
> environments.

Uh, ok, bad wording. It's more about easily changing the values during
testing so that I can use the refined code to deploy it. So it's about
ease of change during development, not in the production stage.

But it would be useful even for boundary testing. You can have one
central point to define a few constants and wont forget to adjust them
if you one day decide to change your code.

Thanks

Arthur