I put together two files. One file (the batch file)
contains the command to run isql with the parameters
required to access the database. This file also identifies
an input file that contains SQL to be processed. The second
file is the input file itself that contains the dump
database sql command.

When I manually log into isql, I can run the dump database
command as listed in the second file and it runs seamlessly.
However, when I run the batch file, nothing happens. Can
someone look at the two attached files and let me know what
I've done wrong. I just can't see what the problem may be.

Regards,
Shawn

PS - I had to submit the bat file in .txt format since it's
not permissible to attach applications and such to postings.
In my world, this file was datadump.bat.

After postig, I noticed I'm not able to open the attached
files so in case others can't open them either, I'll just
post the internal contents of the files here.

The syntax within the batch file is as follows:
run isql.exe -Sserver -Uuid -Ppwd -Ddb
-ic:\temp\datadump.sql -oc:\temp\datadump.out

The syntax within the sql file is as follows:
dump database db to datadumpdevice
go

Thanks,
Shawn

What happens if you issue the 'run isql ...' command from a command window? Does it perform the dump or generate an error?

I don't 'do' Windows scripting (I prefer to use cygwin), but I'm wondering if the scheduled version of your script is
failing to pick up your Sybase environment variables thus leading to a failure of the 'run isql ...' command? (Does the
scheduler have any sort of errorlog that would capture any error messages? perhaps the windows event log?)

Have you tried modifying your batch file to first execute the c:/sybase/sybase.bat script in order to load your Sybase
environment settings, and then issue the 'run isql ...' syntax?

Shawn wrote:

Mark,

No, the environment variables are loaded. When I go into
the command line and type "isql.exe -Sserver -Uuid -Ppwd
-Ddb" it opens the isql window with me automatically logged
into the server and set to the declared database. There
must be some issue with the -i and -o flags. The -i I
thought was to define a Transact SQL input file that would
be processed. The -o was for logging results to an output
file. I've double checked the paths of the files several
times to ensure they are accurate yet when I run my batch
file it continues to write to a Pwd (no extension) file.
Any other ideas?

Shawn

Also, it's worth mentioning that when I'm in ISQL, I can
successfully run the script that's being requested as input
using the -i flag in the master batch file (namely "dump
database db to datadumpdevice").

It's also worth mentioning that the directories and
filenames being used as input and output have no spaces or
dashes in them to confuse isql.

Thus, the problem seems to fall squarely on the use of the
-i and -o flags. Is there another flag that I can use to
issue a solo command rather than requesting an input file
with transact sql statements? If so, a sample would help.

Thanks again,
Shawn

What I was suggesting you try is the full *run isql* command from the command prompt, eg:

C:\>run isql.exe -Sserver -Uuid -Ppwd -Ddb -ic:\temp\datadump.sql -oc:\temp\datadump.out

This should validate the use of the '-i' and '-o' options, as well as validate isql's ability to locate your input file
and write to the output file.

We know that manually logging into isql and manually issuing the command succeeds, what I want you to do is to simulate
what the scheduled job is doing, ie, issue the same command that's being issued by the scheduler.

---------

As for the environment variables ... we know they're loaded ok for your manual attempts, but how do you know they're
loaded successfully by the scheduler process?

---------

And there's still the question of what (if any) messages are generated in the scheduler log when the scheduled job fails
to run? or perhaps the windows event logs?

Shawn wrote:

Mark,

I tried running the full command via the command prompt 2
days ago BUT I wasn't getting any results. I was getting
neither a resulting output file NOR would I see the
resulting .dat file of the dump. Ummmmm...but today is a
different story. ?????

I tried this several times the other day but I was getting
nothing. Yet when I broke the pieces apart and issued the
command excluding the input/output files, it worked. Then I
could request the dump using the sytax from the input file
to do the database dump.

The ONLY thing I can think of other than the inexplicable is
that I tried this BEFORE issuing the first database dump. I
may have been testing using the log dump which of course is
not possible before the initial database dump. However, I
would have expected to have at least gotten the output file
generated with the detail saying such.

Either way, it seems to be working today. What changed
between now and then is anyone's guess...but hey, it's
working.

Thanks for your help!

Shawn

I was mistaken in my most recent reporting. When I run the
command "isql.exe -Sserver -Uuserid -Ppassword -Ddatabase
-iD:\sybase\dump.sql -oD:\sybase\dump.out" by way of
Start...Run...it runs successfully. It process and writes
the output to the out file and backs up the database. If
this same command is embedded in a batch file, run as a
scheduled task, or executed in any other way, it fails.
When it fails, it creates a Pwd file with nothing in it.

Why would it run successfully when issued via
Start...Run...but fail to run in every other way?

Any ideas? We're baffled.

Shawn

As I've mentioned before, my guess is that the scheduled job is not loading your Sybase environment variables, thus
causing the 'isql' command to fail.

What happens if in your script file the first thing you do is run the %SYBASE%/SYBASE.bat file and *then* run the isql
command?

-----------

And *again* ... have you checked the Windows event log around the time that the script is suppose to run? If the script
file is generating an error it will send the error message to the client front-end, but since this is a scheduled job
(ie, no client front-end) there's a good chance that any error messages will get dumped in the Windows event log.

If this is a case of your Sybase environment variables not being sent then I'd expect to see a message in the Windows
event logs stating something to the effect that 'isql' is an invalid command.


Shawn wrote:

I have a feeling this is an ASE 12.5.1 / Windows 2003
compatibility issue. Sybase pulled a not-so-nice one right
after my customer purchased version 12.5.1 some years
back...namely they made version 12.5.2 which was Windows
2003 certified as an upgrade, meaning a USP was required or
the upgrade was only available at a cost.

As my customer's first experience with Sybase, he was not
pleased. We navigated around the install by using Windows
NT compatibility mode THEN after that everything seemed to
be fine on Windows 2003, even though it was not certified
for Windows 2003 by Sybase. It looks like we just found our
first compatibility issue. It has to be...everything you've
recommended makes no difference. The only way it will run
successfully is to run the command from the Run prompt. It
will not run as a scheduled task. It will not run embedded
in a batch file. It just can't be scheduled.

Since there's no support for 12.5.1 any longer, let alone
for 12.5.1 on Windows 2003 Server, my recommendation to him
was to set up a policy to have an employee run this manually
every night. If times were better, I'm sure he'd consider
upgrading but we all know what the economy is like these
days.

Thanks for trying Mark. I appreciate it!

Shawn