P
(PeteCresswell)
I wrote a bond trading/tracking application whose scope creep has
made it a candidate for moving to SQL Server as a back end, and
then for a rewrite of the front end in .NET.
For the "Admin" screen, I just have a tab control with a tab for
each lookup table. The user simply types directly into the
table.
The rational was that this screen is available only to one or two
people designated as "Administrator" and is used maybe once a
month absolute max. e.g. Maybe they want to add a new rating
supplier and some ratings allowed for them; or create a new
"Account" (AccountName, AccountNumber, CurrencyType,
CustodianBank...)
The contractor who will be doing the conversion is troubled by
this screen and wants a subform/add/change/delete/save/edit
checking scenario implemented for each and every tab.
But the application is due tb rewritten in .NET shortly after the
back end is moved to SQL Server.
I say just ODBC to those tables, continue restricting the use of
the screen, and go with that until the .NET rewrite.
Seems to me like SQL Server's constraints will kick in if, for
instance, somebody tries to add an Account with a Null
AccountName... or tries to delete a tlkpState row that is part of
an existing relationship.
In short, I'd hope that it should behave pretty much like it does
now attached to JET tables with the expectation that maybe SQL
Server will throw a few different errors at it.
Opinions?
made it a candidate for moving to SQL Server as a back end, and
then for a rewrite of the front end in .NET.
For the "Admin" screen, I just have a tab control with a tab for
each lookup table. The user simply types directly into the
table.
The rational was that this screen is available only to one or two
people designated as "Administrator" and is used maybe once a
month absolute max. e.g. Maybe they want to add a new rating
supplier and some ratings allowed for them; or create a new
"Account" (AccountName, AccountNumber, CurrencyType,
CustodianBank...)
The contractor who will be doing the conversion is troubled by
this screen and wants a subform/add/change/delete/save/edit
checking scenario implemented for each and every tab.
But the application is due tb rewritten in .NET shortly after the
back end is moved to SQL Server.
I say just ODBC to those tables, continue restricting the use of
the screen, and go with that until the .NET rewrite.
Seems to me like SQL Server's constraints will kick in if, for
instance, somebody tries to add an Account with a Null
AccountName... or tries to delete a tlkpState row that is part of
an existing relationship.
In short, I'd hope that it should behave pretty much like it does
now attached to JET tables with the expectation that maybe SQL
Server will throw a few different errors at it.
Opinions?