Consistent connection failure to vfp - visual-foxpro

I have been working on an API to run queries on a FoxPro database via PHP (v7.3) using ADODB (v5.20.14). Currently, my working solution uses XAMPP (3.2.2 x86), running on a Windows 2019 server. FoxPro driver (6.01.8629.01).
I'm now trying to get this same setup working using IIS 10, however, I'm running into a strange issue where if I send simultaneous requests to the web server, only the last request will return back data successfully; the issue lies in $db->connect. This is the connect code that I am using:
require_once('adodb/adodb.inc.php');
$db = NewADOConnection("vfp");
$ADODB_FETCH_MODE = ADODB_FETCH_ASSOC;
$db->debug = true;
$db->connect("DSN=Visual FoxPro Database;UID=;SourceDB=<UNC PATH>.DBC;SourceType=DBC;Exclusive=No;BackgroundFetch=Yes;Collate=Machine;Null=Yes;Deleted=Yes;") or die("Failed to connect.");
The error that I get back on all but the last request is:
odbc_connect(): SQL error: [Microsoft][ODBC Visual FoxPro Driver]This file is incompatible with the current version of Visual FoxPro. Run 30UPDATE.PRG to update the file to the current version., SQL state S1000 in SQLConnect
I have found this KB article on the error which seems to suggest that it's an erroneous error; it's misleading.
If you open a database located on a server numerous times from multiple Visual
FoxPro 6.0 executables, then the following error randomly appears:
This file is incompatible with the current version of Visual FoxPro. Run
30UPDATE.PRG to update the file to the current version.
This error may also occur if you are opening a Visual FoxPro 6.0 database using
ADO or the Visual FoxPro ODBC driver.
I don't believe that this is very helpful as it works when executed via XAMPP, just not IIS. IIS application pools are set to use x86 as ADODB and the FoxPro driver require 32 bit.
I'm not sure what is causing this behavior and why the last request works every time, the connection to the dB is established and data is returned successfully.

Unfortunately, this seems to be an issue with version 6.x of the VFP driver which won't be fixed as VFP was made end of life some years ago; extended support for v9 ended in 2015, you can see the lifecycle here.
I can't speak for the difference between IIS and XAMPP but they use different underlying technologies.
Considering the age of VFP, I presume that you're using v6 to support a legacy system? In which case, there's no fix for this issue other than to use a third party xBase driver which supports VFP, there are plenty out there and should work for your existing setup.

You are saying ADODB but erroneously using ODBC driver, which latest version was 6.x. You cannot access newer version of VFP tables with that driver. Use VFPOLEDB driver instead, it works wonderfully well with ADODB (32 bits). Unfortunately I am not using PHP, so I can't give an example with PHP.

Related

Oracle ODBC connection failure (using oracle's stock ODBC drivers)

Want to use an Oracle-ODBC connection in Visual Studio 2017/ SSIS as it's much faster than OLE DB during tests.
Problem:
I follow Oracle's steps to the letter.
Install instant client (v18, also tried v12).
Download/ extract ODBC download in same library. Run odbc_install.exe.
See the Driver in 'ODBC Data Sources/ Admin' in Windows 10.
Add new User Data Source. TNS Service names pull up fine. Test
Connection (User/ Pass) -- it works!! The Connection works!!
I tried this with 64 bit in Oracle, their instant client v18.3 or 12.2 both. All works in Window's "Oracle Source Administrator" via test connections.
I tried this with 32 bit downloads as well. All is good.
Now, open Visual Studio. First tried 64 bit (my Windows OS is 64 bit, but Visual Studio Data Tools is only 32 bit). Had a hunch it wouldn't work.
Error message "system architecture and client is not the same" or such. Gotcha.
Tried the 32 bit Oracle ODBC driver (User Source). I keep getting the same message (tried 18_3 and 12_2 versions).
Now .... SQLORA32.dll is in the very file path it named. It's right there! Why can't it be found? The test connection in ODBC Source Admin works! What is going on here?
And I'm unsure if I have to "register" something via the command line, I had to do that once before, maybe it was an unrelated issue.
To boot, when I tried a 3rd party "Devart Oracle ODBC connector" -- it's a simple 5-second install wizard that works flawlessly instantly. Problem is it's a 30-day trial and costs $150 at least. How can I can get an Oracle-created ODBC connector (Oracle being world-renowned for janky-azz products) to actually work?
Devart, and probably Attunity Oracle ODBC: 5 second installs
Oracle's own: Harder to install than breaking into Fort Knox/ learning Mandarin Chinese. Please advise.
I am answering my own question.
Unfortunately some of us ETL/ BI guys need to go so wide on problems that there's no time to figure out every little detail/ glitch of Oracle's ... whatever they're doing now.
But here's a fix. In Visual Studio 2017/ Data Tools/ the SSIS IDE .... if you want an Oracle ODBC connection (Faster than OLE Db for some reason) --- when you're setting it up, instead of selecting a NAMED "user or system data source" that you created in ODBC Source Administrator, simply using the "Builder" option (to the left of Use Connection String) for a connection string. It does the exact same steps as the ODBC Source Admin, but within Visual Studio. I don't know what the difference is here, but some wizardry/// who knows what is different, and the connection somehow, suddenly, for some reason, works.

Oracle 10g forms builder has stopped working

Oracle 10g forms builder has stopped working on Windows 7 Enterprise while opening an existing .fmb file, which was made in same environment.
The user is trying to open an existing form with extension ‘.fmb’ after connecting the form builder application to the oracle database, at that time only the application is showing ‘stopped working’ message. Those forms has been given by DBA team to user. And user needs to modify on those forms. I tried with multiple forms to open through the application, most of them causes the same message to appear and the application is crashing.
There's nothing much I can suggest that will fix your problems quickly. Anyway, here's what I think: you (or, even better, administrators) should check whether Forms version you use is/was supported & certified with operating system you use.
I have Forms 10g, ver. 9.0.4 (it was the very first 10g version, regardless the "9.x" version number) which was supported on Windows XP. That's why I installed virtual machine on my computer, put XP onto it and installed Forms. Everything works just fine.
Now, if it turns out that you're running a combination of Oracle software and operating system that wasn't certified (i.e. there's no guarantee that it'll work), I suggest you do the same. It will take some time to make it up and running (matter of an hour or two), but then you can share that virtual machine among all the developers, without any new installation.
Certification matrix is available at My Oracle Support (MOS); have a look. Also, MOS might even have a solution (patch?) for your problems - search their database.
Stuck in this exact problem and unable to find a fix to this.
I create a form from TEMPLATE.fmb on my Windows 7 64bit machine using Forms [32 Bit] Version 10.1.2.0.2.
The form is created successfully. Then I transfer the fmb to AU_TOP forms folder and compile it using frmcmp_batch, No error. The form is compiled and running.
Now when I transfer that same FMB from AU_TOP to my machine and reopen in form builder, it crashes.
IMAGE

deployed pb App transaction not connected

I have deployed a PB App created with PB12.5 Classic. Its a PB winform app. I have managed to deployed it on a test unit to test its performance. I have created a custom runtime packager.
this runtime packager that i have created consists of basic PB runtime DLL, which is the PBDWE125.dll, PBSHR125.dll PBSNC125.dll, PBVM125.dll as per sybase's instruction in infocenter.sybase.com.
i have also packaged microsoft dlls which is the atl71.dll, libjcc.dll, libjtml.dll, msvcp71.dll, msvcp100.dll, msvcr71.dll, msvcr100.dll and nlwnsck.dll.
all of these dlls are installed in C:\Program Files\Sybase\Shared\PowerBuilder.
my problem is, my PB app is running BUT WHEN I TRY TO ESTABLISH CONNECTION my database server it prompt "Transaction not Connected"
is it the PBSNC problem? i tried registering it using regsvr32 and it didnt work. i have used PB runtime packager but still no luck. i have tried the app path registry and link it to the directory stated above and still no luck...
my question is
is there anything that i can do to make this work?
win 7 has c++ runtime libraries installed already right?
what can be the cause of "transaction not connected" error
what can i do to make it work?
note:
i have user access to the database server
i can access the database server
the app is working when the PB IDE is installed
please enlighten me! thank you :D
Does the computer that the app is deployed to have the SQL Server Native Client runtime installed? (I'm assuming you're using SQL Server because you mention PBSNC125.dll.) Here's some info from a blog post I wrote a while back (I was using PB 12 and SQL Server 2008, so things may be different for you.)
Files Required
On your client machines, in addition to the PB runtimes (including PBSNC120.dll, which is for SQL Server), you also need to install the SQL Server Native Client runtime. These come as an msi installer package from Microsoft. When you install the SQL Server client, you'll need to do so as an administrator. Otherwise you'll get a cryptic error message along the lines of "0: -1".
There's a 32-bit and a 64-bit version of the runtime. The 64-bit version won't run on a 32-bit version of Windows and vice versa.
Footnote: My project used PowerBuilder Classic version 12.1 and SQL Server 2008
"Transaction not connected" usually comes from a DataWindow being given a transaction object that isn't connected to the database. It sounds like there isn't much error trapping when you connect to the database, and you're getting a down stream symptom. You need to add error checking to your CONNECT routine, and that will give you more clues as to what is going on.
One of the more common problems with connections on deployment is when programs try to read connection parameters from an INI file, and on deployment the app can't find the INI file, so with no error checking on reading the INI, the program is trying to connect with an empty transaction object and fails. However, the information you've given us is too late to have any clues whether that is the problem or not.

ADODB Recordset Binding in Windows 7

I have an old VB6 application that uses ADODB recorsets with ODBC connections. The application hs worked fine on Windows XP for years. I tried installing it on 3 different Windows 7 64 bit machines and I get error 545 - Unable to bind to field or DataMember: 'FieldName'.
Here is the code where the error occurs:
For Each oText In Me.txtFields
Set oText.DataSource = rsLocationInfo
oText.Locked = True
Next
Thanks for your help. I have been trying to research and fix this all day.
I figured it out. I'm not sure which data (MDAC?) component was incorrect, but simply installing the Access 2007 runtime on the machines solved the problem. If we continue to use the old VB6 app, we need to revisit our installation package. For now, we're good to go until we rewrite the old app.

adhoc queries using opendatasource microsoft.ace.olebd.12.0 reading excel file

adhoc queries using opendatasource microsoft.ace.olebd.12.0 reading excel file
Everthing was working fine on my local even on production for a long time already "months". As long as the user is a sysad.
And then, just all of a sudden the script using OpenDataSource using microsoft.ace.olebd.12.0 raised an error
OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)" returned message "Unspecified error".
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)".
No one is altering the script
No one has updated the server nor my local.
All of the servers for different apps that uses the script encoutered the error.
I'm really confused already on what happened on the driver? Is this some kind of a expiration on the ace driver??
Hope someone could help me.
Do you still have this issue?
Is it a x32 or a x64 server?
Did you install any windows update?
I get this error using AccessDatabaseEngine_x64 driver, and then just installed the x32 driver (no x64 removal) and it worked just fine. The might be a dll dependency or something. Check if you had any windows update regarding these drivers.
Hope you fixed your problem :D
Regards

Resources