I am running 32-bit Microsoft Access on Windows 8.1 and MYOB Premier 19.10
Have no problem setting up a 32 bit DSN and accessing MYOB in read only mode from Access.
Have installed developer key and have tested connection using TestConnection from MYOB. Test OK
When I now try to link to a MYOB table, I get a ODBC call failed - Cannot launch MYOB #20066 error. Have tried changing MYOB and Access to XP compatibility mode - still the same.
I also get the same error running on a Windows 7 machine.
Can someone please help.
gary
I am not familiar with Access, but if you are going to use a DSN to write to MYOB ODBC tables your connection string must look something like "DSN=YourMyobDsnName;ACCESS_TYPE=READ_WRITE". If Access does not allow you to add parameters to the connection string it's probably not going to work.
Another way connect to the company file is to use an ADO connection string. It would look something like "Driver={MYOAU1001};TYPE=MYOB;UID=Administrator; PWD=MyPassword;DATABASE=C:\PathToYourCompanyFile\CompanyFile.myo; HOST_EXE_PATH=C:\PathToTheMyobExecutable\MYOBP.exe;
ACCESS_TYPE=READ_WRITE;DRIVER_COMPLETION=DRIVER_NOPROMPT;KEY=AAAA...DDDD". Your paths and credentials will of course differ, as may the version of MYOB ODBC you are using. 10.01 is the most recent version in AU.
Following your comments I looked into it and now understand this capability is not available in Access. A common approach is to create a small executable that exchanges information between MYOB v19 ledgers and whatever it is you need to integrate with. Again, I am not an expert but it seems to me that you could use VBA in Access to accomplish this. VBA can use the ADO libraries.
I had to disable UAC on Windows 10 to get MYOB to launch via ODBC:
https://superuser.com/questions/83677/disabling-uac-on-windows-7
I created an MLOAD job using OleLoad on my Windows 7 x64 Professional machine. It loads data from Oracle 11g into Teradata 14. Everything works great when I run it locally. When I copy it to a remote Windows Server 2003 SP2 machine and run it, it fails with error code 12 and this message:
**** 07:30:57 UTY4203 Attempted to access out of range input data in field
'LOCATION_CODE', file 'myjob.amj',record number '1'.
**** 07:30:57 UTY4023 Access module warning '33' received during
'PreserveRestartInfo' operation: 'Attribute name not recognized by attached
AM'
I opened my .amj file on the remote machine to see what it would look like if I regenerated it using OleLoad's UI. When comparing the two .amj files in Beyond Compare afterward, I was surprised to see that the new .amj is very different. VARCHAR(214) is changed to FLOAT, VARCHAR(30) is changed to VARCHAR(10), etc.
All TTU 14 assemblies on the remote machine match what I have installed locally. The only difference I noticed is the verison of Oracle DLL that OleLoad appears to be using. Here's what OleLoad says on my machine when I click on Connection Info for my Oracle connection:
Provider
Name: OraOLEDB11.dll
Version: 11.2.0.1.0
DBMS
Name: Oracle
Version: 11.2.0.3.0
And on the Windows Server 2003 machine:
Provider
Name: OraOLEDB.dll
Version: 9.0.1.0.1
DBMS
Name: Oracle
Version: 11g
Now before anyone facepalms with "Well, DUH! There's your problem!", I'll add that it will cause me a great deal of grief if I had to install a new version of Oracle on my local machine because I have a ton of MLOAD files that I've created for personal utilities (helper loads, if you will, for when the business needs ad hoc report). I can't upgrade what's on the remote server because I'd run the risk of breaking all of the other MLOAD jobs that are running there.
I just wanted to mention all of that in case it was relevant, but I am hoping that it's not actually the problem and that there's a way I can get my current file to work without having to uninstall/reinstall/upgrade anything.
I believe that the theory proposed at the end of my OP has been confirmed. I was able to find a machine that had Oracle client 11 installed and migrated my jobs there. They worked flawlessly, so it is most certainly an issue with Oracle 9 client vs 11.
I've created some Web API methods in .NET 4 / Visual Studio 2010 (and have now ported it to VS 2013 RC).
I want to consume them from a Windows CE / Compact Framework app using RestSharp.
Regardless of how I call these methods, though, I need to know the IP Address to use for the app running the Web API methods. I can access it from a browser using "localhost" and the port number Visual Studio displays when running the View for the Web API project in the browser (works fine, returns XML in Chrome).
But: how can I call it from my Windows CE / Compact Framework app? The emulator in which I run it doesn't believe that it and localhost are really on the same machine, so I can't use that, nor the machine's actual IP address as, again, it is delusional about who/where it is.
So: what is the workaround? How can I test this?
More details about this can be seen here: RFC on HttpWebRequest vs RESTSharp from Windows CE / Compact Framework 3.5
UPDATE
Vasily, my guess was that you meant for me to do this:
...but that led to this:
Note: I get the same when I choose the other option from the dropdown asociated with the "Enable NE2000 PCMCIA network adapter and bind to:" czechbox, namely "Intel(R) 82579LM Gigabit Network Connection".
And trying to install http://go.microsoft.com/fwlink/?linkid=46859 (both the 64-bit and the 32-bit flavors) slapped me with:
So tell me, I implore: Is there balm in Gilead, so that there may be joy in Mudville tonight?
UPDATE 2
In step 6 (bullet 6), I did this:
...which got me first a message that the software didn't install correctly, with the option to retry or assert that, no, everything is really fine (I chose the latter), but then this:
...IOW, I don't make it to step/bullet point 7
Then again, this Peek cat did warn, "Note that this is very much a “works on my machine” experience. If it burns your house down, don’t hold me responsible."
My house didn't burn down (I don't think - I'm not there right now), but the process to extract the file did fail ignominiously.
You can use workstation network card by the emulator. Todo it you have to select "Use installed network card" checkbox and select the card from the list. after that you can use the workstation ip.
This was helpful for me:
Windows Virtual PC and the Microsoft Device Emulator
I've had to use it more than a couple of times.
I saved the file as a PDF to my network folder, so it took me a while to find the link.
Well, I've searched the interwebs like crazy and I am unable to find this driver.
I am trying to convert data from a client's database that was built using the ASA 8.0 engine. ASA 8 has been out of support since 2008. The software company that created this no longer supports it, so can't provide me with the drivers. I've scoured the web and can't find anything.
I managed to get the installation files for this old software called BailCredit built by a company called SentryLink. I found what I presume to be the ODBC driver in the installation files (dbodbc8.dll) and I've tried manually registering that (Windows Server 2008 R2) but didn't get anywhere. When I try to create a new datasource, the ODBC Data Source Administrator gives me an error.
My company has done hundreds of data migrations and this is the first time I've had to resort to this.
I'd post a link to the database file, but simply can't because of privacy.
Please help if you can! Thanks in Advance.
Matt
For 64 Bit operating system you need to copy the dll's to %windir%\syswow64\ so you need to change install.cmd to the following code. The rest is the same.
COPY %~dp0dbcon8.dll %windir%\syswow64\dbcon8.dll
COPY %~dp0dblgen8.dll %windir%\syswow64\dblgen8.dll
COPY %~dp0dbodbc8.dll %windir%\syswow64\dbodbc8.dll
regedit %~dp0SAS8.REG
pause
It take's me a few hours to figure it out i hope it help someone else.
This is how I finally solved it.
OPTION 1:
Get a copy of the following files from a computer with a working setup of the SQL Anywhere ODBC driver:
dbodbc8.dll
dbcon8.dll
dblgen8.dll
Create an install.cmd file with this:
COPY %~dp0dbcon8.dll %SystemRoot%\system32\dbcon8.dll
COPY %~dp0dblgen8.dll %SystemRoot%\system32\dblgen8.dll
COPY %~dp0dbodbc8.dll %SystemRoot%\system32\dbodbc8.dll
regedit %~dp0SAS8.REG
pause
Create an SAS8.REG file with this:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Adaptive Server Anywhere 8.0]
"Driver"=hex(2):25,00,57,00,49,00,4e,00,44,00,49,00,52,00,25,00,5c,00,73,00,79,\
00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,64,00,62,00,6f,00,64,00,62,00,\
63,00,38,00,2e,00,64,00,6c,00,6c,00,00,00
"Setup"=hex(2):25,00,57,00,49,00,4e,00,44,00,49,00,52,00,25,00,5c,00,73,00,79,\
00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,64,00,62,00,6f,00,64,00,62,00,\
63,00,38,00,2e,00,64,00,6c,00,6c,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\ODBC Drivers]
"Adaptive Server Anywhere 8.0"="Installed"
Run install.cmd
This will work when Windows is installed in C:\WINDOWS, otherwise edit the registry entries.
OPTION 2:
If someone left a copy of the Powerbuilder CD in the client's computer, look for the folder asa801runtime and install that to get the ODBC driver working
EDIT:
Example connection string with default username/password:
Driver={Adaptive Server Anywhere 8.0};UID=dba;PWD=sql;DatabaseName=base;EngineName=gestion;CommLinks=TCPIP(HOST=GRA06:2638)
Answering my own question:
I wasn't able to find this commercially available anywhere. I happened to be able to get my hands on the installation for the software package that was using SQLAnywhere 8. By installing this, it installed the necessary drivers (but only worked on 32-bit OS).