[dba-SQLServer]ODBC connection - Is this normal

John Colby jcolby at colbyconsulting.com
Tue Oct 7 12:38:19 CDT 2003


Francisco,

I would LOVE to port my entire app to an ADP, just haven't had the time.  If
I am to use my framework I have to not break it in the process.  I designed
the framework in Access long before ADP even existed and when it came time
to rewrite it I was faced with taking the time to do so such that it worked
in both environments or just get it working again in A2K.  I had stuff to do
so I took the easy route.

As anyone who's been on the list for long knows I have one very serious
piece of code that handles Active / Trash flags for me.  I also have a
control which I call Rec_ID because it is always bound to the record ID (an
autonumber as we all know).  These specific items get referenced in my
framework a LOT.  Because the REC_ID control always contains the PK of the
current record of whatever table a form is looking at, it becomes trivial to
use that as a pointer to the current PK.

These and a small handful of other specific controls on every form  get
referenced in my framework, and are used to filter SQL statements, sometimes
directly, more likely in a VB function that examines the control.  Either
way, it doesn't port easily to SQL Server which doesn't understand either my
custom VB Functions nor controls on forms.

It IS possible to work around these problems by feeding the control values
into parameters in SProcs in SQL Server.  I started to do so, and just got
sidetracked.  Even if I do that, I have to pretty much rewrite any existing
application, build these custom SProcs, etc.  Not something I can just "pop
in a new framework" and go.

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 11:43 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [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


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com






More information about the dba-SQLServer mailing list