I had an application perfectly working under Windows XP (32 bit). Moving to Windows 7 (64 bit) and compiling gives me the error run time error 429 ActiveX component can't create object in the module (second line, "set mydb=...", see code) where I make the connection with the MS Access database (Access 2013 in Windows 7 64 bit). In Windows XP it was an Access 2000 database with extension .mdb. Now it is Access 2013 with extension .accdb.
In the references I replaced the Microsoft Office DAO 3.5 library with the Microsoft Office 15.0 Access Database Engine Object Library, but this doesn't solve the problem. (If I leave the DAO object library, then I get run time error 3343 unrecognized database format on the same line.)
I'm not sure if I have to put in the components of the forms the 32 or the 64 bit version. (For example, dbrgid32.ocx under windows\system32 or under windows\sysWOW64 ... or does it not matter?)
Sub pldata()
Set mydb = DBEngine.Workspaces(0).OpenDatabase("D:\ETC\Gegevens\ETC2015.accdb", False, False, "MS Access")
'Set mydb = DBEngine.Workspaces(0).OpenDatabase("D:\ETC\Gegevens\ETC2015.accdb")ess")
Set myrstadres = mydb.OpenRecordset("select * from dbadres order by naam")
End Sub
Related
I am using neo4j enterprise 3.0.3 version for windows. Following the operations manual 3.0, I have installed the neo4j service with bin\neo4j install-service. But I can't start it with bin\neo4j start. It said
Invoke-Neo4j : Failed to start service 'Neo4j Graph Database - neo4j (neo4j)'.
And I can't start the neo4j service in windows serice either. Maybe anyone have encountered this case before?
I had the same problem: I am using neo4j community 3.1.2 for windows and installed the service with the neo4j.bat file without any problems.Then i wanted to start the service with neo4j.bat and got the same error as you
I found a solution that worked for me. My neo4j files were in a folder, where the path to the folder contained spaces (C:\Program Files\Neo4j) Then i moved the folder one level up (C:\Neo4j).
After that i could start the service without problems.
Maybe this solution helps.
I am running neo4j on windows and in my case the crux of the issue was that there was an incompatibility between the installed versions of Java (32-bit) v/s OS version. The biggest clue that led me to this is the following set of lines in neo4j-service.2018-08-03 log file
[2018-08-03 14:55:42] [info] [ 1432] Starting service...
[2018-08-03 14:55:42] [error] [ 1432] %1 is not a valid Win32 application.
[2018-08-03 14:55:42] [error] [ 1432] Failed creating java C:\JavaNew\bin\server\jvm.dll
[2018-08-03 14:55:42] [error] [ 1432] %1 is not a valid Win32 application.
[2018-08-03 14:55:42] [error] [ 1432] ServiceStart returned 1
There are a fair number of potential issues, and I have made an attempt to compile all the issues with this,
Windows services cannot deal with service names in folders that have spaces; especially if there is another folder with the same name as the one with spaces.
For example - C:\Program Files... will have issues if C:\Program\Something...
To work around this, I put Neo4j in root folder c:\Neo4j
Get-Java.ps1 (under ..\bin\Neo4j-Management folder)looks in the path variable for 'JAVA_HOME' (usually found in *nix environments). If it does not find it here, it keeps looking in registry, and finally throws up its hand!
To deal with this, I simply put in a path variable. For a good measure, I uninstalled Java and re-installed Java in the root folder under C:\JavaNew
In retrospect, this step is probably not on part of the problem, and hence can be ignored. But I am leaving it here for completeness sake.
Invoke-Neo4j.ps1 (also under ..\bin\Neo4j-Management folder) has code that determines if the OS is 32-bit (or 64-bit). Based on this it determines if it should run prunsrv-i386.exe (32-bit) or prunsrv-amd64.exe (64-bit).
This has to match the Java version installed.
Upon running java -XshowSettings:all, and inspecting the sun.arch.data.model value (32, in my case), I realized that my OS is 64 bit and the Java version is 32-bit.
To deal with this, I put in code (very klugey!). I am sure there are much better ways to get to the same outcome, but this is what I used.
switch ( (Get-WMIObject -Class Win32_Processor | Select-Object -First 1).Addresswidth ) {
32 { $PrunSrvName = 'prunsrv-i386.exe' } # 4 Bytes = 32bit
#64 { $PrunSrvName = 'prunsrv-amd64.exe' } # 8 Bytes = 64bit COMMENTED as a workaround!!!
64 { $PrunSrvName = 'prunsrv-i386.exe' } # 8 Bytes = 64bit
Now, uninstall the neo4j service, install it, and start the service.
Hope this works for you.
neo4j console
Posting for latest versions > 4.x
I had the same issue using neo4j start, Neo4j console is the right command I was looking for. It is a web-based graph that acts as an interactive tutorial.
i had the same problem , after the neo4j worked for few weeks it stoop working (without any change that i made)
i have set java_home uninstall and install and now it works
neo4j-enterprise-3.3.4
I was also having weired issue as there was no error but neo4J service did not start.
[xx#ss1 bin]$ ./neo4j console
[xx#ss1 bin]$ .
The problem was with the permission on Java directory and I tried
chmod -R 777 jdk_directory
and problem got solved.
#neo4j #neo4jnotstarting
I am writing an application (using .NET Framework 4.5.2 + SQL Server 2014 installed locally). The application needs to support both SQL Server 2014 and previous versions.
When reading data using the inbuilt SQLCLR-types (SqlGeometry, SqlGeography, SqlHierarchyID), the standard ADO.NET methods (e.g. DataReader.GetValues()) use the 10.0.0.0 assembly, and throw an exception due to a mismatch with the loaded (v11 or v12) version.
The reasoning is documented (though it takes a while to spot) in the Breaking Changes in SQL Server 2012 (for the 11.0.0.0 assembly). For SQL Server 2012, there are three workarounds listed:
Use Type System Version=SQL Server 2012 in the SQLConnection.ConnectionString
OR: Use app.config / runtime / assemblyBinding / dependentAssembly to re-map v10.0.0.0 to v11.0.0.0
OR (not a very "neat" way to handle it): rewrite your own code to manually deserialize from a SqlBytes instance...
When developing from a computer with SQL Server 2014 installed, the assembly version is v12.0.0.0, and similar issues arise:
System.InvalidCastException: Unable to cast object of type Microsoft.SqlServer.Types.SqlGeometry to type Microsoft.SqlServer.Types.SqlGeometry.
For SQL Server 2014 (other than the horrible manual deserialize approach), there only seems to be one workaround (not officially documented in the breaking-changes) - it would appear that the v4.5 SqlConnection hasn't yet caught up with the version of SQL Server:
Use app.config / runtime / assemblyBinding / dependentAssembly to re-map v10.0.0.0 to v12.0.0.0
Question: other than re-mapping v10.0.0.0 to v12.0.0.0 in app.config (which seems to work), is there any other (easier) approach that will use the referenced assembly version?
A quick code-example below shows the failure (without the assembly-remapping in place):
private static void DoStuff()
{
SqlGeography geog_val = SqlGeography.STGeomFromText(new SqlChars("POLYGON((-122.358 47.653, -122.348 47.649, -122.348 47.658, -122.358 47.658, -122.358 47.653))"), 4326);
SqlGeometry geom_val = SqlGeometry.Parse("LINESTRING(1 1,2 3,4 8, -6 3)");
prm_geog.Value = DBNull.Value; prm_geom.Value = geom_val; ReadReturnedSpatialColumns(cmd);
prm_geog.Value = geog_val; prm_geom.Value = DBNull.Value; ReadReturnedSpatialColumns(cmd);
}
private static void ReadReturnedSpatialColumns(SqlCommand cmd)
{
using (var dr = cmd.ExecuteReader(CommandBehavior.SingleRow))
{
dr.Read(); var items = new object[2]; dr.GetValues(items);
var geog_test = dr.IsDBNull(0) ? SqlGeography.Null : (SqlGeography)items[0];
var geom_test = dr.IsDBNull(1) ? SqlGeometry.Null : (SqlGeometry)items[1];
}
}
This issue still exists with Framework 4.6.1 and there appears to be no workaround apart from the 3 you've already discovered. So the short answer to your question is no.
However I would question if you really need version 12 of the spatial types, because (as far as I can tell) they don't add anything over the v11 types. If you'd prefer to use the v11 types so you can use the Type System Version=SQL Server 2012 workaround, you can install the Nuget package that incorporates all three versions (10, 11, 12) - it's specifically designed to allow you to deploy to servers where MSSQL may not be installed.
As a bonus, referencing that package directly and using Type System Version=SQL Server 2012 will ensure that your app will always be using the 2012 spatial types, so upgrading to SQL 2016 won't break anything if it decides to return a different version of them (e.g. 13, or 14, or whatever 2016 will use) by default.
I'm working with WinDbg 6.12 with both serial port connection and named pipe connection. Unfortunately I'm unable to connect my WinDbg with the target (NT 4 SP 6a) from the begining of the OS boot, autoreconnect doesn't work and I need to wait until NT 4 timeout for kernel connection is reached. Then NT continues with the startup process and only then I can connect...
Where I can get a version fully compatible with NT 4? (I have already checked the oldest version from Microsoft Debugging Tools website)
Also, where can I get the NT 4 symbols for debugging? I'm afraid the Microsoft Symbols Server doesn't provide these symbols anymore.
Thanks,
For futher details, the kd log is:
Opened \\.\pipe\com_1
Waiting to reconnect...
Connected to Windows NT 4 1381 x86 compatible target at (Tue Jan 24 16:32:17.010 2012 (UTC + 1:00)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: srv*b:\out*o:\out*http://msdl.microsoft.com/download/symbols
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntoskrnl.exe -
CS descriptor lookup failed
Windows NT 4 Kernel Version 1381 UP Free x86 compatible
Machine Name:
Kernel base = 0x80100000 PsLoadedModuleList = 0x80150b70
System Uptime: not available
The call to LoadLibrary(kdextx86) failed, Win32 error 0n2
"El sistema no puede hallar el archivo especificado."
Please check your debugger configuration and/or network access.
Unable to get program counter
WaitForEvent failed
Unable to get program counter
0008:497a 0010 add byte ptr [bx+si],dl
kd>
Works with http://msdl.microsoft.com/download/symbols/debuggers/dbg_amd64_6.7.05.1.exe
From Windbg 6.12 help:
"Windows NT 4.0
Debugging Tools for Windows no longer supports the debugging of Windows NT 4.0 targets.
If you want to debug a Windows NT 4.0 target computer or perform user-mode debugging on Windows NT 4.0, you should use Debugging Tools for Windows version 6.7.5.1. You can install this package from the Debugging Tools for Windows Web site."
I have been getting a stackoverflow exception in my program which may be originating from a thirdparty libary, microsoft.sharepoint.client.runtime.dll.
Using adplus to create the crash dump, I'm facing the problem that I'm struggling to get any information from it when i open it in windbg. This is what I get as a response:
> 0:000> .restart /f
Loading Dump File [C:\symbols\FULLDUMP_FirstChance_epr_Process_Shut_Down_DocumentumMigrator.exe__0234_2011-11-17_15-19-59-426_0d80.dmp]
User Mini Dump File with Full Memory: Only application data is available
Comment: 'FirstChance_epr_Process_Shut_Down'
Symbol search path is: C:\symbols
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Machine Name:
Debug session time: Thu Nov 17 15:19:59.000 2011 (UTC + 2:00)
System Uptime: 2 days 2:44:48.177
Process Uptime: 0 days 0:13:05.000
.........................................WARNING: rsaenh overlaps cryptsp
.................WARNING: rasman overlaps apphelp
......
..WARNING: webio overlaps winhttp
.WARNING: credssp overlaps mswsock
.WARNING: IPHLPAPI overlaps mswsock
.WARNING: winnsi overlaps mswsock
............
wow64cpu!CpupSyscallStub+0x9:
00000000`74e42e09 c3 ret
Any ideas as to how i can get more information from the dump, or how to use it to find where my stackoverflow error is occuring?
The problem you are facing is that the process is 32-bit, but you are running on 64-bit, therefore your dump is a 64-bit dump. To make use of the dump you have to run the following commands:
.load wow64exts
.effmach x86
!analyze -v
The last command should give you a meaningful stack trace.
This page provides lots of useful information and method to analyze the problem.
http://www.dumpanalysis.org/blog/index.php/2007/09/11/crash-dump-analysis-patterns-part-26/
You didn't mention if your code is managed or unmanaged. Assuming it is unmanaged. In debugger:
.symfix
.reload
~*kb
Look through the call stack for all threads and identify thread that caused SO. It is easy to identify the thread with SO, because the call stack will be extra long. Switch to that thread using command ~<N>s, where is thread number, dump more of the call stack using command k 200 to dump up to 200 lines of call stack. At the very bottom of the call stack you should be able to see the code that originated the nested loop.
If your code is managed, use SOS extension to dump call stacks.
Loading Dump File [C:\Crash_Mode__Date_12-05-2009__Time_15-54-2727\PID-4056__CCNET.EXE__1st_chance_Process_Shut_Down__full_13d0_2009-12-06_00-33-14-734_0fd8.dmp]
User Mini Dump File with Full Memory: Only application data is available
Comment: '1st_chance_Process_Shut_Down_exception_in_CCNET.EXE_running_on_TEST218'
Symbol search path is: srvE:\symbolshttp://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Version 3790 (Service Pack 2) MP (2 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Machine Name:
Debug session time: Sun Dec 6 00:33:14.000 2009 (GMT+8)
System Uptime: 32 days 12:43:52.414
Process Uptime: 0 days 8:44:37.000
..........................WARNING: mscorjit overlaps mscoree
..............................WARNING: wldap32 overlaps dnsapi
..........WARNING: rasapi32 overlaps dnsapi
...WARNING: tapi32 overlaps rasapi32
.WARNING: rtutils overlaps rasman
..............WARNING: setupapi overlaps winsta
....wow64cpu!CpupSyscallStub+0x9:
00000000`78b842d9 c3 ret
why this happen?
Not related to CLR, instead it's 32-on-64 as described here http://www.dumpanalysis.org/blog/index.php/2007/09/11/crash-dump-analysis-patterns-part-26/ -- in short use the following:
.load wow64exts
.effmach x86
With those, kb and !analyze -v will give better results.
I hadve seen the same thing latly, I do not know for sure but it's probably some WOW64 artifact or possibly due to some more aggressive anti-exploitation techniques. At leat on Win32, even though the load address of a DLL may be different on occasion, if a DLL is mapped in antother process (like ntdll/kernel32) when your process start's if it is statically linking these DLL's also, it would always load at the same address until the next reboot.
It seems probable that more recent CLR exe's are able to remap various module's per-execution, I know that this is an issue on MSVC10 and Windows7 but perhaps it's been ported to additonal platforms for CLR applications.