I am curious about opinions on this. Obviously if you are an ISV developing Add-Ons for many clients, or if you are on Native then this does not apply but...
We all know that moving from Native to SQL is a common process, but does anyone move the other way? My guess would be "pretty unlikely". So if a client is on SQL, and you are developing customizations for them, is there any logic behind writing code so that it is optimized for both Native and SQL? Wouldn't it make more sense to just optimize for SQL and be done with it? On the same topic is SETCURRENTEY (ignoring th SQL 2005 issue and hinting Read Waldo's Blog or Mark's Blog for more about that).
Basically I know we should be covering all options, but is it really the best solution for our clients if we are thinking about Native DB for a client that will never use it?
David Singleton:I am curious about opinions on this. Obviously if you are an ISV developing Add-Ons for many clients, or if you are on Native then this does not apply but... We all know that moving from Native to SQL is a common process, but does anyone move the other way? My guess would be "pretty unlikely". So if a client is on SQL, and you are developing customizations for them, is there any logic behind writing code so that it is optimized for both Native and SQL? Wouldn't it make more sense to just optimize for SQL and be done with it? On the same topic is SETCURRENTEY (ignoring th SQL 2005 issue and hinting Read Waldo's Blog or Mark's Blog for more about that).Basically I know we should be covering all options, but is it really the best solution for our clients if we are thinking about Native DB for a client that will never use it?
Well, David, I think you answered yourself - if you are developing a customization which has no chance of being reused anywhere else but in the environment you are in, to keep it simple by dropping useless code would be the right thing to do.
In light of my last post about LS Retail, I wanted to bump this for more opinions.
Thanks.