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