Hi there,

I'm trying to use a tool to export my data to a pipe-delimited file for upload to another location. I need this data to be exported weekly and then uploaded to an FTP server.

I'm using the Adagio-ODBC connector for this purpose and I have a tool that works quite well when logged in, but it cannot work when the user is logged off. I have had the author of the software looking into it for me and he assures me that the splash screen and status bar windows that the Adagio-ODBC connector displays are infringing Windows' ability to run the command line action as a task when not logged in.

My question is:

Has anybody had to run an export like this before and come across this same issue?

and, if so,

can we make it so the connector doesn't display the windows? The windows are pretty much useless as I know that my data is being accessed. Perhaps add some settings so these windows can be turned on and off?

Any help would be greatly appreciated.

thanks
Lucas

Have you considered using GridView to produce an Excel spreadsheet that is then saved as a PSV file? Or how about just using the export templates built into Adagio?

When you say the ODBC connection "doesn't work", are you sure that you have the correct SYS password on the command line or ODBC connection definition it's using? is the CaSiNg correct? How about leaving the workstation logged in and just "locking" the keyboard rather than logging out?

I doubt it's the splash screen causing the problem - and that's unlikely to disappear as it contains our copyright notice.

Yes, I have.

Gridview does not allow you to export blank-formatted workbooks as it insists on formatting and freezing panes. You cannot export workbooks with only one worksheet. You can also only export to the xlsx file format which isn't always an option for different parties requiring the data. ODBC offers an open standard for open communication

Adagio does not allow for scheduled exports or command line options. The exports should be configured on our neutral server where a user is not always logged in for security reasons.



Oh the connection works perfectly...when not run from a scheduled task without a logged in user. The problem occurs when the task is attempted to run when the user is logged out



Actually, I'm quite confident that this IS the case. Scheduled tasks have issues when there is window-tracking involved. Since your connector insists on creating new windows, it creates issues with tasks running without a GUI



This makes little sense for a paid-for program. Are you saying that you need to inform users who have already shelled out the $1200 for your module that they have already shelled out $1200? I understand this for the trial version, but it makes zero sense for somebody who is already committed - both financially and technically - to your product.

The splash screen shows once a day on each machine that runs ODBC. The "progress bar" is the real issue and I don't know if we can detect the "machine state" to bypass this screen activity. Eliminating the "progress bar" completely would not be acceptable for long queries.

Using Server 2003, while not logged in, I tested a scheduled task using a Batch file.
The Batch file called GridView with the /XDW parameter. GridView autoloads and refreshes 4 Views then exports those views to Excel. Lots of screen activity when logged in but the scheduled task worked correctly ( with no screen activity ) when NOT logged in.

I did need to restart the server to get the scheduled task to work.

I will put some simlpy VB script together to test ODBC but I do not think screen output is a problem.

Hi Michael,

Thanks for the reply and testing.

I'm running this on Server 2008 R2, but I also tested it on 2008 as well. I have not, however, tried to restart the server to get it all to work. I will do so and report back.

thanks
Lucas

Hey Michael,

I can confirm that restarting the server does nothing on Server 2008 R2. The Task Scheduler says the command completed successfully but nothing has happened and the export file does not appear.

Is there any way you can test on an upgraded version of Windows Server?

I have tried creating the task through the GUI Task Scheduler as well as using the AT command. Can you please confirm the method you used to create the task?

Have you tried setting things up to "Run As Administrator" or making sure that "Allow non-administrators to run this program" is selected.

Try to set up a "Schedule Task" on the Server to use a Batch file to copy some files around on the server when not logged in.

Test while logged in..

Log out and allow the schedule task to run. If you can do this then the same type of process should work for OLEDB.

If you can't get this type of simple function to work it is unlikely you will get your application that uses Adagio ODBC to work.

Scheduled Tasks in general have major problems with "mapped drives".

Google "scheduled tasks and mapped drives" for additional information.

I have no problem running Adagio ODBC on Server 2008 R2 as long as I stay away from referencing mapped drives in ADSPROF, the ODBC DSN, the Batch file and registry entries for ADSDRM.

Schedule tasks are NOT impacted by screen activity, that is Splash Screens or Progress Bars.