[dba-SQLServer]ODBC connection - Is this normal

I don't want to get into an MS Access vs Other Tools argument.  The fact 
is that if you've never used .ADP's then you either don't know what 
you're talking about, or you gave up due to lack of documentation.  It's 
all the same after all.  I won't knock ASP nor VB/.net (even C#) 
development, however IME, it's far quicker to develop in an Access ADP 
than it is in ASP, VB, .Net, C# (whathaveyou) even when you are not 
"BINDING" the forms, to Tables/Views/Sprocs.  Almost every other 
environment requires additional development time.  And w/ Access ADP's, 
you can still access advanced Windows Features and API's or 3rd party 
.DLL's etc.  There really is no limit.

Additionally the Rules have also changed in SQL Server in which Dynamic 
SQL (aka On-The-Fly SQL) is frowned upon for more than just performance 
deficits, but because it exposes your tables...  That being said. 
Sometimes it may seem necessary to use Dynamic SQL, but w/ proper 
planning and effort you can overcome most of those hurdles.

Djabarov, Robert wrote:
> Wow, so choosing the right tool for the job is as bad as body piercing,
> whips and chains?   AND, you dare to call it "framework"?????
> "On-The-Fly SQL Statements"????  Man, I must be missing something very
> simple, and wasted all my life not being able to see it...wonder what
> the heck it is... Oh, I get it, it's MS Access used as a RAD tool!!!!
> 
> Good luck  
> 
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of John
> Colby
> Sent: Tuesday, October 07, 2003 2:17 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: RE: [dba-SQLServer]ODBC connection - Is this normal
> 
> 
> 
>>>Very normal.  It's also normal to drop Access as your FE and do
> 
> everything using something more robust like C#, C++, or even VB.
> 
> Yea, in the same circles where it is normal to tie each other up, pierce
> body parts and use whips and chains for sexually deviant purposes.
> 
> 
>>Or even abandoning the .mdb part of Access and building it as an ADP, 
>>then
> 
> that problem goes away completely and you still retain some of the RAD
> attributes of building it w/ Access.
> 
> True.  And for those of you who don't use a framework, or who designed
> their framework from the ground up to use SQL Server that is certainly
> an option. My framework does things not easily ported to SQL Server
> (on-the-fly SQL Statements referencing form controls for example).  One
> of the reasons that I moved my billing app to SQL Server is to slowly
> start the process of porting the framework.  To this point, life has
> gotten in the way of THAT project.
> 
> John W. Colby
> www.colbyconsulting.com
> 
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
> Francisco H Tapia
> Sent: Tuesday, October 07, 2003 1:10 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer]ODBC connection - Is this normal
> 
> 
> Djabarov, Robert wrote:
> 
>>Very normal.  It's also normal to drop Access as your FE and do 
>>everything using something more robust like C#, C++, or even VB.
>>
> 
> 
> Or even abandoning the .mdb part of Access and building it as an ADP,
> then that problem goes away completely and you still retain some of the
> RAD attributes of building it w/ Access.
> 


-- 
-Francisco