ODBC DSN Error
Last post Dec 07, 2004 07:26 PM by Anonymous
Dec 06, 2004 06:56 AM|Anonymous|LINK
I'm looking at setting up a database of event logs. I'm using a VBScript to backup and clear some event logs. Then a shell script that calls logparser to query the logs and output their contents to a SQL Server. I'm just in the early stages of testing all
this out, and I know about the issue of having the contents of the messages lost when running log parser on a second machine without the dll's and regkeys that contain and point to the message data. I'm hoping this will be resolved in 2.2 as it is reported.
I would like to know some details about how this hurdle is going to be jumped.
Right now though I'm running MSDE on my desktop trying to parse my own workstations logs into a database. i'm getting the following error when I run the batch file that calls logparser. I'll probably convert the batch into VBS at some point.
Here's the line from the shell script and the error message I'm getting, I think it has something to do with the fact my ODBC DSN is pointing to a local copy of MSDE, but I'm not sure what to change to overcome it;
LogParser -i:EVT -o:SQL "SELECT * FROM *_application.evt To APPLICATION" -dsn EVENTLOGS
Error connecting to ODBC Server
SQL State: 08001
Native Error: 17
Error Message: [Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server
does not exist or access denied.
Thanks in Advance
IISODBC input format
Dec 06, 2004 07:42 AM|Anonymous|LINK
Well, as with all the DSN problems, you should double-check the connection parameters you've specified for the EVENTLOGS DSN. Log Parser doesn't do anything special with a DSN - it just uses its name and asks the ODBC subsystem to connect to it.
Now, the ODBC applet has a "test this connection" utility...what happens when you try that?
P.S.: The 2.2 change wrt event log messages is that 2.2 will first try to find the dll's locally; if the dll's can not be found, it will try to load the
Dec 06, 2004 10:53 AM|Anonymous|LINK
I thought I already posted a reply but it doesn't seem to have come up, here I go again.
A test of the DSN completes successfully. I've tried deleting and recreating it as a system and user DSN.
I had this all working with an access database, but the max 255 character in the message field was causing truncation (worked without the message field though!).
I think i'm going to write this up in VBS and use a DSN-less connection. I think it has somehting to with the ODBC DSN and the MSDE instance being on the same system. I read something about that but I haven't really been able to find any helpfull information
on how to get around it.
Regarding 2.2, will going out to a machine on the network to get the dll's be fairly lightweight network traffic wise? Will the data in the dll's be maintained locally after the first time this is done for each unkown message or will the remote server need
to be accessed each time an unknown message arises?
I'm still trying to decide if it would make more sense to run log parser against the backed up log files locally on each server and then output the data to CSV, transfer the csv's to a central location and use them as the input for the database. Many of
the servers are in different sites, so WAN traffic is always a concern.
Thanks for your response, I appreciate it.
Dec 06, 2004 11:41 AM|Anonymous|LINK
InBan, since the command you provided doesn't include a -username property to accompany the DSN, the error probably indicates one of two things:
Remember, System DSNs don't store user credentials (the value stored under HKLM\ODBC\ODBC.ini\[DSN name]\LastUser is there only to assist with the configuration through the DSN configuration utility).
Dec 06, 2004 12:02 PM|Anonymous|LINK
Alright, it works, forget about the DSN, I looked at the syntax again and realized you were right on the money, I was neglecting the username and password. This line works. Sorry for the dumb question!
LogParser -i:EVT -o:SQL "SELECT * FROM *_application.evt To APPLICATION" -server COMPUTER -database EVENTLOGS -username USER -password PASS
Dec 06, 2004 09:09 PM|Anonymous|LINK
Glad to see the DSN problem resolved.
Regarding the EVT question, yes, 2.2 caches the remote DLL's locally, so LP will only load a remote DLL when it encounters it for the first time (or when the cache is full, which I believe means > 64 dll's accessed).
Dec 07, 2004 04:52 AM|Anonymous|LINK
Dec 07, 2004 07:09 AM|Anonymous|LINK
Dec 07, 2004 07:23 AM|Anonymous|LINK
That sounds like the way to do it. I'll have to try that out.
Thanks alot Gabriele, it's a great tool.
PS I imagine you're getting sick of this question but; when will 2.2 be available?
Dec 07, 2004 07:26 PM|Anonymous|LINK
Dec 08, 2004 02:52 AM|Anonymous|LINK
I'll keep my eyes peeled for it.