My program is build by VS2022 with address sanitizer enabled. It works in my own PC(win11). But when running it in windows server 2008 r2, it reports error like "cannot locate PssQuerySnapshot in KERNEL32.dll". It seems the system is too old to support this function.
Without address sanitizer, the program works. The program do has some memory bugs which only trigger in the server, so I want to use address sanitizer to find them.
Does anyone know how to make it work? Maybe the easiest way is to upgrade system to higher version, but I cannot do it.
Related
My Problem is that I cannot connect to an SQL Server Express 2008 64bit Database via an Access Runtime 32bit, neither by Windows authentification nor by SQL auth.
On the Windows 2011 Small Business Server runs a Virtual machine with Windows 7 Prof. 32 bit. From this Windows I tested my Access App. using a (32bit) SQL Driver 11, which works fine.
The same Access App used from a 64 bit Windows 7 Prof. Client using a 64bit SQL Driver 11 fails with SQLState 08001 error.
The Thing which I do not understand is, that ODBC Connection test is successful, a data link (UDL) is successful, but not my Access App.
When starting the app, the first Thing is to run a stored procedure through a passthrougquery and grab data from a certain tbl in the SQL-Database. This SP brings the Connection error, but not an runtime error from Access (I removed even an error handler!).
So, how can I find the reason or any error in the Access app (if there is one)?
I am helpless as anything I know to test or to do I already tried out to make the app run. As I cannot even install the SQL Driver 11 in 32bit, it should not be a Driver related error.
Does anyone know a test-app, where I cannot only connect but retrieve data from an SQL-Database or any other tricks to check the Access to the database?
Thanks your help!
Access usually is installed as a 32bit Application. So on 64bit computers it will use the 32bit subsystem. On Windows 7 all the default shortcuts to the ODBC Data Source Administrator utility will lead to the 64bit version of it. Whatever you see or configure there is completely irrelevant, as your 32bit Access is not going to see it.
Solution:
You need to explicitely open the 32bit version of the ODBC Admin utility and configure the data source there.
To make sure you get the right version, use Windows Explorer and open this file: C:\WINDOWS\syswow64\odbcad32.exe
Well, what I found out meanwhile is, that the Connection Fails when trying to use a Connection like this "ODBC; DSN=MyDSN;....." but it works, when I make a Connection DNS-less, by connecting with "ODBC;DRIVER=SQL Server Native Client 11; SErver=myServer;....".
Maybe this is exactly that what you are talking aout. When I just use a DSN it takes the wrong bit Version.
So I will try this: delete the DSN I have, open odbcad32.exe and create the same DSN again.
If I understand you correct, then Win 7 provides the correct Driver and stores it in the DSN. Calling this DSN by Access would lead to the correct Settings.
Further Problem is, that my SSQL-Server instance is not at port 1434, and the SQL Server Native Client 11 Driver has no more Clientconfiguartion to set the static port. So I found a string solution for that "MyServer\Myinstance, 15999".
I hope that this port Setting will be accepted in the DSN, otherwise I really have to Change to DSN-less which is more complicated due to different Servers for the development and the production.
Thanks yr. reply.
I have read everything I can find on the net about "class not registered".
I have a vb Com dll which I have installed on the server.
(I did not write the DLL an don't have the source) The server is 64 bit
I have a 32 bit program (Delphi7) on a 64 bit machine.
The program does a cocreate with the server name and gets a "class not registered".
If I put the program on the server and run a cocreate it works, the class is registered.
In desperation I did an install of the DLL on the local PC and the cocreate works
I checked the registration on both machines, it is identical, and the registry
HKEY_Classes_root_wow6432Node\CLSID\ on both machines has the registration GUID.
The setup/registration process on each machine being identical.
Why does it create when the call is local (on both machines) and not when the call is remote?
It would seem that the remote call from PC to server even though from a 32 bit program is being seen by the server as a 64 bit call.
Note: the server is a virtual server, does this make a difference?
Any help much appreciated.
The server has a program called Pastel Partner which uses Pervasive Btrieve
The VB6 DLL (and associated DLLs) are simply a separate program which can be accessed via the interface to provide certain functions like an input of an accounting entry into the Btrieve Files instead of typing it into the Pastel Program.
My program starts of course with a create of the interface, which seems to work if My program (32 bit) is run on the server as createobject(class), but not when it is run on a remote PC with the server name.Createobject(class,server) when the class not registered occurs.
It is the server which is a virtual server.
Local and Remote are different. To access remotely, you have to grant access.
I didn't quite get your problem and I have no idea what server you are using so if this will help, click for details... https://rtcamp.com/tutorials/mysql/remote-access/
or you can specify your search methods like how to remotely access "database" and whatnot.
If your problem is not really the remote access on your database then try this. This might be of help. http://www.theogray.com/blog/2009/10/comexception-regdbeclassnotreg-on-64-bit-windows
P.S. If you are using virtual machine, it is already considered like using a different PC.
I am working on an application in my free time and I want to use a SQL Server database. I have the .iso for SQL Server 2008 R2 Developer but I don't have an extra computer to dedicate as a server. I assumed I could use VMware Player for a virtual server but from what I've read it seems that I would need VMware vCenter or another paid version.
Is there a free option for creating a SQL Server database virtually? This will be extremely small scale (3 tables and just for my personal use) so I am not worried about performance at all.
You can install that locally on your computer. There is no need for a virtual engine. Even if some of the MS documents say you need a server operating system, that is not the case. The setup has a check for valid operating system, and it just installs fine on Windows XP, Vista, 7 in my experience.
But if you want, VMWare Player would also work. In contrast to its name, you can also create virtual engines with it - but with some limitations.
And for a really small solution, even SQL Server Express, which is also free, would do. If I remeber correctly, the main restriction is that the data may not exceed 1 TB.
SQL Server can run locally without any problems, even in your dev/gaming/browsing computer without creating too much interference. There is no problem in installing it for testing and even for production of small systems (the express edition is free and valid for those uses).
Another, even slimmer, alternative, if you dare to upgrade to SQL 2012, would be to use a new feature called LocalDB. It's basically the very same db engine with a very important difference: it does NOT run as a service, but instead it's a regular program that is automatically started when a connection is attempted. Advantages would be that it does not consume resources until it's needed and yet you've got almost the full feature set of the real server. Here is an introduction on it. While I've never used it (always with the full express version), it seems good for the kind of programs you want to develop.
I recently installed SQL Server 2008 Express on my Windows 7 Ultimate x64 home machine. I also have IIS 7.5 with PHP 5.3, and I was trying to connect to SQL via ADODB, but kept getting this error:
[Microsoft][ODBC Driver Manager] The specified DSN contains an
architecture mismatch between the Driver and Application
After doing a small amount of digging on the internet, I think this is because the SQL Server ODBC driver is meant for 32-bit operating systems, and mine's 64. First of all, am I correct? Is this the reason I'm running into trouble? Secondly, if so, how do I fix this? Are there any updated ODBC drivers that work with 64-bit operating systems? I looked but was unable to find any...
You're right in that it has to do with the bits.
Hope this helps:
--From MSDN --
To manage a data source that connects to a 32-bit driver under 64-bit
platform, use c:\windows\sysWOW64\odbcad32.exe. To manage a data
source that connects to a 64-bit driver, use
c:\windows\system32\odbcad32.exe. If you use the 64-bit odbcad32.exe
to configure or remove a DSN that connects to a 32-bit driver you will
receive this message.
I've been having the same problem trying to link a 64 bit SQL 2012 server to 'Sage Timberline' using Pervasive ODBC Client Interface.
I can set up the 32 bit DSN, but SQL Server keeps giving me the "architecture mismatch" error when trying to create a linked server using the 32 bit DSN.
I tried the C:\Windows\SysWOW64\odbcad32.exe to add the driver. But when I set up a linked server between MAS90 and SQL Server 2008 R2 I still get the architecture mismatch error. Just spoke to a guy from Sage and he says it won't work with 64-bit edition of Sql Server. The linked server works with MAS90 only if the edition of Sql Server is 32-bit.
I'm betting you are working with User DSNs.
Depending on your perspective, there's a "feature" or "bug" in the 64-bit Windows environment --
32-bit User DSNs show up in the 64-bit Administrator and when 64-bit client applications ask for all available DSNs -- even though the 32-bit DSNs cannot be used by the 64-bit client app and Adminstrator.
64-bit User DSNs show up in the 32-bit Administrator and when 32-bit client applications ask for all available DSNs -- even though the 64-bit DSNs cannot be used by the 32-bit client app and Adminstrator.
The error message you describe comes up anytime there's such a bitness mismatch between the DSN and the client trying to work with it.
Microsoft's recommendation is to name your User DSNs with _32 or _64, depending on the bitness of the driver on which they're based ... or stick with System DSNs.
There are 32-bit and 64-bit solutions for the connection you want. The bitness of your client application(s) -- IIS & PHP, in this case -- dictate the bitness of the solution you require.
if 32 bit application on 64 bit operating system (the application you are installed under [program files (X86)] use the following
C:\Windows\SysWOW64\odbcad32.exe
otherwise 64 bit application and 64 bit operating system use the following
C:\Windows\System32\odbcad32.exe
otherwise you will get a error like "Architectural mismatch"
Hope this will save someone's day :)
This worked for me:
Updated solution, make sure the IIS application is NOT set to 32-bit on x64 Windows. More info:
http://forum.gpsgate.com/topic.asp?TOPIC_ID=13711
from:
http://forum.gpsgate.com/topic.asp?TOPIC_ID=13622
Currently running Server 2003 but am looking at reinstalling in the near future due to a change of direction with the domains. Should I take this opportunity to install Windows Server 2008 instead?
I would love to play with new technology and the server is only for a small home business so downtime/performance issues aren't really a concern.
I am no expert on Windows server revisions, but the only new feature of Server 2008 I can think of is Hyper-V. But I would try Server 2008 just for Hyper-V, as this VM hypervisor is supposedly much faster than VMware and Virtual PC, and is compatible with Virtual PC virtual disks.
One rule that has served me very well over the years is: Do not upgrade infrastructure components just for the sake of upgrading. If it works well, leave it be. You mentioned that some downtime isn't a big deal, but if the server is actually used then there is a chance it can become a big deal unexpectedly. Why not simply get (or build) a new machine and play with the new operating system there? That way you get the best of both worlds.
There is no Exchange Server 2008. Exchange has always been tightly integrated with IIS which tends to bind it to a specific version of Windows. However, Exchange Server 2007 SP1 can be installed on Windows Server 2008.
Exchange Server 2003, however, cannot run on Windows Server 2008 and I do not believe there are any plans to do so in a future service pack.
Note that Exchange Server 2007 requires x64 architecture, running the 64-bit OS, on a production system. The days of booting /3GB are past - it simply does not provide enough virtual address space for current large databases. Exchange's long-running virtual memory fragmentation problem has not been fixed, it has just been given more virtual address space to work in.