We are migrating some jobs from a server we are retiring to a different server. The server specs are as follows:
OLD: 32 bit - Windows Server 2003 SP2
NEW: 64 Bit - Windows Server 2003 SP2
The job runs both manually and through scheduling on the old server without error. This is because there is a client on the old server. The only option for running it on the new server is to schedule it. When it is scheduled, it fails with the following results.
(LPWVW6629) 4/26/2012 6:21:14 AM: GetandProcess.batch: Execution started
(LPWVW6629) 4/26/2012 6:21:15 AM: Verification \LPWVW6629\E$\WFSC\PAR\Centerprise\Settings\AlltelImport\GetandProcess.batch: Verification failed. Error accessing database table for verification. ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified.
(LPWVW6629) 4/26/2012 6:21:15 AM: GetandProcess.batch: Execution ended
(LPWVW6629) 4/26/2012 6:21:15 AM: GetandProcess.batch : Execution terminated due to error. Error accessing database table for verification. ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified.
(LPWVW6629) 4/26/2012 6:21:15 AM: Error information written to file://\Lpwvw6629\WFSC\Centerprise\Staging\lnd_cabq_sa_pu\Log\GetandProcess.err
I have also attached the error log referenced in the output.
<?xml version="1.0" encoding="utf-8"?>
Error accessing database table <untitled> for verification. ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified.
Microsoft Windows NT 5.2.3790 Service Pack 2
This batch reads from an Access database and that is where it is failing. My thought is it may be the 32-Bit vs 64-Bit difference with either Centerprise or Access.
I noticed that it mentions something about ODBC in the error message. Is this how you are connecting to your data source?
If so, do you have the DSN set up on the new server?
There is no DSN installed on either server.
This is from the developer:
There are no DSN (User, System, or File) created on the old server.
I noticed that there were no 64-bit MS Access drivers on the new server. There is only the 32-bit MS Access Driver installed on this server. I went ahead and downloaded the 64-bit MS Access driver to the NEW server.
I scheduled the import process, and it throws the same error when scheduled on the old server.
The Astera Service has been restarted as well.
This looks like it is running into a 32 / 64-bit issue. I’m going to set you a program that will switch the “bitness” of our .NET executable. This should make it run as before.
Try downloading and running the bat file that has been emailed.
See if you are then able to connect and run to your Access databases. I just thought about the SQL CE aspect of this. But, I am not sure if switching it will be compatible. But try it anyway to see if it at least solves your Access problem. We can deal with SQL CE if it comes to that.
That did not work. Attached is the error our developer received when trying it.
You’ll have to modify the bat file to point to the location of corflags.exe (it is included in the zip file that I have emailed). Note, this is not a permanent solution, but just something I would like to try to see if my hypothesis is correct.
I got this from the developer. Do you have any suggestions?
I don’t know. But after I ran that batch program. The Astera Service on the new server did not start. There are production files that need to be loaded tomorrow for CABQ that relies on this server. How do we get it back and running?
Event Log Message:
Event Type: Error
Event Source: Astera Integration Server
Event Category: None
Event ID: 0
Service cannot be started. System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
at Astera.Database.DbProviderBase.set_Factory(DbProviderFactory value)
at Astera.Database.DbProviderBase…ctor(String dataTypeResource, Type dbTypeEnumType, DbProviderFactory factory)
at Astera.Database.SqlDbProviderBase…ctor(Type dbTypeEnumType, DbProviderFactory factory)
at Astera.Transfer.Server.TransferService.OnStart(String args)
at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)
I thought this might happen. This is a result of us switching the build to 32 bits without taking into consideration the SQL CE files (which are 64-bit). To immediately get back to the way we had it before, run the batch file again, but this time with a /64 parameter.
In the meantime, I’ll start on a new 4.x build that will take care of the correct dependencies and we’ll try with that one. Also, let me know if you try to manually copy the SQL CE dependencies into the server directory.
Our developer will give it a try today. In the meantime, we will wait for the build package with the right DLLs. If our developer efforts work, I would like him to use the build package to install to our UAT environment and if all is well, the same package for deployment to Production.
Hi, I have emailed you the new build.
Please keep in mind this does not upgrade any SQL CE files Centerprise uses. The focus of this fix is to eliminate any issues caused by running as a native 64-bit executable. You should now be able to use the same transfers that were using Access before. Let me know if you have any questions.
This executable did not work. Our developer installed the development package on lumzm6633. Install went smoothly but errors appeared when scheduling the jobs.
I also verified some things. I created a one-step batch (copied from the existing one). It contains a step to pull data from an access DB and push it to a SQL server.
When I run it on my machine through Centerprise (server: development) it runs fine. When I run it on my machine with the server: luwzw6633, it fails with the following error.
LUWZW6633) 5/16/2012 12:01:25 PM: This is a NON-PRODUCTION server and is not to be used in a production environment.
(LUWZW6633) 5/16/2012 12:01:25 PM: jkb.GetandProcess.batch: Execution started
(LUWZW6633) 5/16/2012 12:01:25 PM: Verification \luwzw6633\WFSC\PAR\Centerprise\Settings\AlltelImport\jkb.GetandProcess.batch: Verification failed. Error accessing database table for verification. ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified.
(LUWZW6633) 5/16/2012 12:01:25 PM: jkb.GetandProcess.batch: Execution ended
(LUWZW6633) 5/16/2012 12:01:25 PM: jkb.GetandProcess.batch : Execution terminated due to error. Error accessing database table for verification. ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified.
(LUWZW6633) 5/16/2012 12:01:25 PM: Error information written to file://\Luwzw6633\wfsc\CenterpriseStaging\n620149\Log\jkb.err
I get the same error when it is run through a scheduled task.
I think this is a problem with the Access driver not being 64 bits compatible. There are no 64-bit office 2007 drivers but there is a 64-bit office 2010 driver. It is installed on the server, but our server is not listed as it is compatible with the 64-bit version. The server we are running on is Windows 2003 SP2 and the 64-bit driver is listed to work on the Win2003 R2 server. I don’t know what the difference is. I wonder if we run the app as 32-bit and get the right SQLCE DLLs in place, it will work.
This build was supposed to run the server as 32 bits. Can you click on the server info screen and tell me what the “64bit” label reads? It should be “no” with this latest version.
It is listed as 64-Bit: Yes
Also noted is that the build version is 184.108.40.206.
I also did some more research overall R2 thing. The installation of Windows 2003 SP1 is equivalent to R2. We have 64-bit office drivers on the machine along with a 64-bit installation of the Astera Integration Server. I am attaching the batch we are running for your review. We are pointing to a specific Access file, so a DNS entry is not required, nor do we have it on machines that are working.
Also, our developer installed the package you sent on our DEV server, and according to the information that we are getting from it, the build version is 220.127.116.11.
This is the wrong version. It should be 4.0.94. Perhaps the upgrade failed? Was the service restarted? Can you try uninstalling and then installing if this is the case?
The message from our developer:
Here is what I’ve done so far:
Uninstalled Astera on LDWZW6635.
The Astera service will not start afterward.
I ran the bit switcher:
Restarted the Astera service. Service starts
The version of Astera shows correctly as 18.104.22.168
However, the test connection to the Access db still fails.
The whole point of 4.0.92 is so that the bit switching program is not needed. We were trying to get it to run as 32 bits. Just like it did on your 2003 server. The idea is that if it did, it would solve any problem relating to 32 vs 64-bit.
What is the error you are getting when the service tries to start and fails? You can look in the event log for this.
Please see attached from our developer It looks like the new build worked with some restrictions.
“*Can you check with the Astera representative if we can get a full version of this 32-bit build? Right now, the build says it is “Restricted to 300 records at a time.” *
*It looks like it is working. I don’t see any errors when the process is scheduled to run. However, there is a discrepancy I have noticed. The output Excel file that is created on dev and UAT using production data is far less than the file it creates on production. I would like to re-test the import in dev and UAT without the record limitation. *
Also, once we get a fully working version of this build (with no limitations) can we install this 32-bit version on LDWZW2503? This is the only place where there is a client version of Astera once the old server is decommissioned.
Otherwise, when you step through the GetandProcess.batch transfer file (on LDWZW2503), clicking the green, right-handed arrow icon to advance to each step, you should be able to see each step…Source Connection, Destination table, etc. However, you get the following attached error window when you try to walk into the step where the transfer file reads the Access database from the server location. On the 32-bit version on the old server, you can walk into each step without getting a missing Access driver issue.
In addition, when you hit Verify the formation of the batch, you get the following missing driver error messages.”
The error seems to still pop up though when verifying the batch. Also, we are likely going to need another license of the client for the development server as I cannot install this on the server our developer is requesting.
I’m a little confused about the configuration based on the developer’s document. The restriction that the developer is facing is because no server license is being applied. You will have to enter the key that you already have on this machine to use it as a server.
But in another screenshot, I see the “Development” server active in the dropdown indicating that this has an embedded server in it. Is this the same machine?
We are making some progress. I was able to install the key (took two tries) on the dev server and I informed the developer. He is going to do some more testing.
When we are running a batch or transfer from the client on Machine X, and we want to test it on Server Y we need to make sure the dropdown at the top says Server Y correct? That will make it run on Server Y’s server versus the inproc server on the client on Machine X?
You are correct. When clicking the green “play” button, whichever server is selected in the dropdown will be the one executing the dataflow.
Let me know if you are successfully able to run this.