Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Command 2.0 Problems With ODBC

 [1/8] from: kvince::comcast::net at: 1-Sep-2005 18:57


Greetings, I'm trying to delete records from a MS SQLServer table based on identifiers stored in a file. The script listed below works great on its own. The problem is launching the script from a third party scheduling app gives me an ODBC error - "** Script Error: ODBC error: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified". The script is launched from the scheduling app with the command: C:\Rebol\REBOLCMD.EXE %/C/Rebol/deltdlrows.r. This brings up a REBOL/Command console with the above error. With this console I can't connect to my database, but when I bring up a new console the connection works fine. Any ideas? REBOL [ Title: "Delete TDL Rows" Date: 15-Aug-2005 File: %deltdlrows.r Author: "Ken Vincent" Version: .05 ] change-dir %/F/Process_J5P0 source: %UPDTDL.DAT connect-db: open odbc://OHSU\*******:[******--DSS42] db-port: first connect-db if [size? source > 0][ tx_nums: read/lines source foreach tx_num tx_nums [insert db-port["DELETE smsdss.clarity_tdl_tran WHERE (TX_ID = ?)" tx_num]]] close connect-db

 [2/8] from: greggirwin::mindspring::com at: 4-Sep-2005 12:06


I haven't seen that under those particular circumstances, but the URL parser isn't always happy with things I've fed it. Have you tried using a block for the scheme? e.g. db-conn: open [ scheme: 'odbc target: "OHSU\*******:[******--DSS42]" ] -- Gregg

 [3/8] from: compkarori::gmail::com at: 5-Sep-2005 7:51


[kvince--comcast--net] wrote.. apparently on 1-Sep-2005/18:57:17
>Greetings, > > With this console I can't connect to my database, but when I bring up a new console the connection works fine. Any ideas?
Does it work if you run it from the command line viz rebcmd %script.r ??
>source: %UPDTDL.DAT >if [size? source > 0][
This is a problem. Source is now of type file, and *if* this were contained in parentheses, then it would error as ">" evaluates before "size?", and expects to see an integer on the left, and not a file. But since it is in a block, the expression is always true as it never gets evaluated. It should read something like this inf: info? %UPDTDL.DAT if inf/size > 0 [ ... ] -- Graham Chiu http://www.compkarori.com/cerebrus http://www.compkarori.com/rebolml

 [4/8] from: kvince::comcast::net at: 6-Sep-2005 21:10


Yes, I can start cmd and run the script successfully with the command C:\Rebol\rebolcmd.exe %/C/Rebol/deltdlrows.r. -------------- Original message --------------

 [5/8] from: compkarori:gma:il at: 7-Sep-2005 10:02


At this point, I suspect it because your scheduling application does not have the same user rights as when you run it yourself. Now this is beyond my experience, but is it a system DSN or a user DSN? On 9/7/05, [kvince--comcast--net] <[kvince--comcast--net]> wrote:
> Yes, I can start cmd and run the script successfully with the command C:\Rebol\rebolcmd.exe %/C/Rebol/deltdlrows.r.
-- Graham Chiu

 [6/8] from: compkarori:g:mail at: 7-Sep-2005 10:18


Just another thought. You can try a direct connection bypassing the DSN. This is from the manual with amendments " In cases where you do not have control over the ODBC control panel to set up a DSN for your database or where you may want the higher efficiency, you can connect to a datasource wihtout using a DSN. Instead of using the URL syntax, a block is pased to open. The block has the following syntax: connect-name: open [ scheme: 'odbc target: join "{DRIVER=Microsoft Access Driver (*.mdb)}; " "DBQ=c:\Databases\mydb.mdb" ] where SCHEME is always set to 'odbc, and TARGET is a complete connection string defining the datasource, driver, and any other needed parameters. The example above uses a Micrsoft Access database and driver. Any number of standard and driver-specific parameters may be passed in the target string." On 9/7/05, Graham Chiu <[compkarori--gmail--com]> wrote:
> At this point, I suspect it because your scheduling application does > not have the same user rights as when you run it yourself.
<<quoted lines omitted: 3>>
> -- > Graham Chiu
-- Graham Chiu

 [7/8] from: kvince:comcast at: 6-Sep-2005 22:37


I made the change you suggested, but still received an ODBC error. Are you sure about the target string? -------------- Original message --------------

 [8/8] from: kvince::comcast::net at: 7-Sep-2005 0:00


Now I feel really stupid! I thought it was setup as a System DSN, but it wasn't! I didn't think of asking our server group to double-check the DSN setup. They created a new entry in the System DSN and now the script works from the scheduling app!! Thank you Graham!!! -------------- Original message --------------

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted