[dba-SQLServer]ODBC connection - Is this normal

Djabarov, Robert Robert.Djabarov at usaa.com
Tue Oct 7 13:22:30 CDT 2003


The syntax is ok, I think you have something like '123,321.21' in the
field (I am not 100% sure about that because the error you posted is
different from the error you would get if this particular value was
attempted to be inserted into a "moola" field).  You may also do some
additional validation within your CONVERT function, like:

CONVERT(money, nullif(isnumeric(varchar_field), 0))

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Nicholson, Karen
Sent: Tuesday, October 07, 2003 2:02 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer]ODBC connection - Is this normal


So why you guys are arguing, can anyone please tell me what is wrong
with my syntax to cast varchars to money?  Please?

-----Original Message-----
From: John Colby [mailto:jcolby at colbyconsulting.com]
Sent: Tuesday, October 07, 2003 1:38 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer]ODBC connection - Is this normal


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




_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com
_______________________________________________
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