Hi John
> That is the only thing that makes sense to me. Do you know this for certain?
Yes. Please see
https://docs.microsoft.com/en-us/windows/desktop/winprog64/file-system-redirector
> I had hoped that by having LEP display the console, I could tell which
> version of PowerShell was run
To
Aloha Keith,
> The reason that you think the 64-bit PowerShell is working is because
> actually the 32-bit PowerShell is still being used.
>
> When a 32-bit application (in this case 4D) accesses the system32 directory,
> those accesses are automatically redirected to the SysWow64 directory.
>
Aloha John
The reason that you think the 64-bit PowerShell is working is because actually
the 32-bit PowerShell is still being used.
When a 32-bit application (in this case 4D) accesses the system32 directory,
those accesses are automatically redirected to the SysWow64 directory.
So when you u
> On May 30, 2019, at 10:13 PM, Keisuke Miyako via 4D_Tech
> <4d_tech@lists.4d.com> wrote:
>
>> QBXMLRP2.RequestProcessor
>
>
> is the QB SDK based on COM / OLE ?
Yes.
> but it does sound like the SDK is not installed in the client having a
> problem.
> perhaps OLEVIEW.EXE could te
> On May 30, 2019, at 9:40 PM, Epperlein, Lutz (agendo)
> wrote:
>
> we use Powershell a lot, even in conjunction with 4D. But we never divide
> between 32bit and 46bit-Powershell. Since you use the Powershell via LAUNCH
> EXTERNEL PROCESS (LEP) the architecture (bitness) of the Powershell bi
> QBXMLRP2.RequestProcessor
is the QB SDK based on COM / OLE ?
if yes,
it shouldn't be a huge problem that information specific to 4D+PowerShell+QB is
rather hard to find,
because COM /OLE is a common technology on Windows.
PowerShell is just one of the ways to invoke it.
in theory, generic
Hi,
we use Powershell a lot, even in conjunction with 4D. But we never divide
between 32bit and 46bit-Powershell. Since you use the Powershell via LAUNCH
EXTERNEL PROCESS (LEP) the architecture (bitness) of the Powershell binary
shouldn't matter.
And a question: Regarding your script how do you
Not sure anyone is interested, but after a lot of research on line it appears
that 64bit version of Powershell cannot call a 32bit dl and vice versa. This
does not match the results I am getting with v17R3.
In my previous post I left out that . 4D client is running on a 64bit Windows
10 instal
Oooops. Just noticed an error in the code I posted. The case statement should
have read
On May 29, 2019, at 7:12 PM, JOHN BAUGHMAN wrote:
Case of
: (32bit PowerShell). //pseudo code.
$FilePath:="C:\\Windows\\sysWoW64\\WindowsPowerShell\\v1.0\\powershell.exe
-file \""+$ScriptPath+"
I ran the PS scrip in the 64bit PowerShell ISE and I am getting the error…
80040154 Class not registered
Googling this tells me that this is the result of 64bit PowerShell balking at
calling a 32bit COM object. I wonder, however, why when run from a 32 bit 4D
Client the same scr
Anyone using PowerShell on Windows 10 out there? Maybe you can help me figure
this out.
I am upgrading an old v13 database to v17. My ultimate goal is to have
everything run-in 64bit.
The database talks to QuickBooks on a Windows 10 machine using an XML stream in
a Powershell script file execu
11 matches
Mail list logo