I have spent 2 days chasing this one round and round, and I have tried several solutions (detailed below).
Problem. When retrieving Geographical data from a Microsft SQL Database I get an error
DBServer routine OpenDataSet has failed with error DataReader.GetFieldType(3) returned null.
From what I have read, this is typically because the project cannot load or access Microsoft.SqlServer.Types, so it can't interpret the returned data effectively
What I have tried;
Removing and readding the reference.
Setting the assembly to copy Local
Removing and reinstalling via Nuget (v14.0)
Referencing said assembly in the web.config
Adding a utility class in Global.asax, then calling that on Application_Start to load in the other dependent files
LoadNativeAssembly(nativeBinaryPath, "msvcr120.dll")
LoadNativeAssembly(nativeBinaryPath, "SqlServerSpatial140.dll")
The error happens whether I am running locally (not such a key issue) or on an Azure vps (SqlServer Web Edition).
The stored procedure I am calling to return the data works fine. (In fact, this code is a lift and shift project. the old vps works fine if we fire it up, so it is most likely a configuration issue and all the above I have done is wasted effort. But the original developer is not contactable, nor are there any notes on how this was made to work.)
Related
I have written a rather complex application in Microsoft Access. It is split into front end and back end files. To protect my code, I have compiled it and saved it as a runtime .accde file, which I then changed to an .accdr file to ensure it operated as a runtime. I have created two versions of the application: one for those with 32-bit Office installed and one for those with 64-bit office. I have used Inno Setup to package the application, the data file, and other files such as the icon file, the license file, etc., into an installable package, which works just fine.
Among my team of 27 beta testers of this application, so far 6 have downloaded it, and I have tested it on four of my own computers. On seven of these computers, the installation works perfectly and the application runs with no problems.
On the computers of three of my testers, when they try to run it, they get this error message:
The expression On Open you entered as the event property setting produced the following error: Bad file name or number.
* The expression may not result in the name of a macro, the name of a user-defined function, or [Event Procedure].
I'm pretty sure I know where the code is that's causing the problem, but cannot for the life of me figure out why the application crashes on those 2 computers but not on others.
The On Open event I suspect of causing the problem checks the linked tables, gets their connect string, then looks at the path for that string for the back end database. If it does not find it there, the procedure pops up a file selector dialog and instructs the user to find the data file, then it relinks all the tables.
If anyone could point me in the right direction to fixing this problem, I would be extremely grateful.
This is typically caused by a reference labelled as MISSING.
You have two (three) options:
Run the application on the offending machines with a full version of Access that lets you debug the code
Create a small test application that lists and verifies the references you use, and run this on the offending machines
Remove those two customers
Thanks to all the contributors here. Because of these folks and additional online research, the latest answer I can find is this:
This error occurs on a small percentage of computers on which the app is installed, and no one has yet figured out why, what causes it, or how to fix it. The workaround is to install the 2013 version of the Access runtime, as later versions will still cause the problem.
At least one of the offending computers is running the Click-to-Run version of Office. Still gathering information, but that's the status as of now.
A large number of our clients operating a split front end/back end Microsoft Access application we built are encountering frequent but intermittent database file corruption issues. When the back end file is opened this message appears: "Microsoft Access has detected that this database is in an inconsistent state, and will attempt to recover the database … "
Opening the database with DAO using Visual Basic code results in error code 3343, "Unrecognized database format."
The repair attempt succeeds and we have not witnessed any data loss or dropping of primary keys, indexes, or relationships. Most cases involve where the back end file is located on a shared network drive. Some searches suggest that the latest Windows 10 update 1803 is suspect. Has anybody else encountered this?
It has recently been reported several times. A very thorough coverage of this issue can be found here.
Strangely, the cure can - at least for some cases - be found in old support threads:
Moved to Server 2012 getting Access Database Corruption
Cannot access shared files or folders on a drive in Windows Server 2012 or Windows Server 2012 R2
Comments:
It’s a bit strange though as the patch to fix the issue is back in May
2014 which is already installed on the server.
I can only think that
something in the latest Windows 10 Build 1803 has brought up the issue
again as it was PC’s that are running that build were causing the
problem.
The fix is adding the following entry into Vospers Server
2012 R2 registry:
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
Value: DisableLeasing
Type: DWORD
Data: 0x1
We testing this on our server and the problem went away. As soon as we
changed the ‘Disable leasing’ value to ‘0’ again, the problem
returned.
I can’t find a reasonable explanation yet as to why this
has started to happen last week but if it works and doesn’t cause any
further issues elsewhere then I’m ok with that.
Also note that homegroups have been removed from Win10 1803. This may affect rights on shared folders.
Good morning.
I'm in the process of writing a vb.NET forms application that will read in a selection of .xlsX files and import their contents into a SQL2012 database. Because the files are in different folders and are all formatted differently, I'm having to write it so that each folder's contents is handled by its own dedicated module. However, one thing that's common across each folder is the process that I need to go through, which is to open each file, read its contents into a DataTable, carry out any manipulation required (i.e. removing empty rows) and then run a SqlBulkCopy to load the data into SQL before moving the original file into an archive location.
So far, so good. I've written and successfully run three of these modules, but the fourth one is giving me the error that's detailed in the Title of this post - the exception is thrown at the point where I'm trying to open the connection string to the Excel object. Again I stress that I've done this three times before, and each time has been successful.
Also, I've noticed that the exception only occurs when running the code in Debug mode. If I run it in Release mode it works without any complaints.
I'm developing this application in a 64-bit environment (VS2010 on Windows 8.1), but targeting the application to x86. I'm happy to continue writing in Release rather than Debug mode, but I'm curious as to why it works in one but not the other and I'd like to be able to code for both modes if at all possible.
TIA
I'm using MigratorDotNet to manage Rails-style migrations for my web app. I have a workflow where, if I delete all the tables in the database, I can access an installation view that will run MigratorDotNet and create all the necessary tables.
This works locally. For some reason, when I upload my code to my Arvixe hosting, the migrations just never run. I get this odd error:
There is already an object named 'SchemaInfo' in the database.
This is odd because, prior to running migrations, I manually deleted all the tables in the database (to make sure it wasn't left over from a previous install).
My code essentially boils down to:
new Migrator.Migrator("SqlServer", connectionString.ToString(), migrationsAssembly).MigrateToLastVersion();
I've already verified by logging that the connection string is correct (production/hosting settings), and the assembly is correctly loaded (name and version).
Works locally, but not on Arvixe. How do I troubleshoot this?
This is a dark day.
It turns out (oddly) that the root cause was my hosting company used a schema other than dbo for my database. Because of this, the error message I saw (SchemaInfo already exists) was talking about their table.
My solution, unfortunately, was to rip out MigratorDotNet and go with FluentMigator instead. not only did this solve the problem, but it also gave me a more intelligible error message (one referring to the schema names).
While it doesn't seem possible to auto-set the schema, and while I need to switch the schema on my dev vs. production machine, it's still a solvable problem (and a better API, IMO). I googled, but did not find any way to change the default schema in migratordotnet.
I'm sorry for the issues that you were having. On shared hosting, unfortunately the only way that we may be able to change the schema is manually. If you are still looking for a solution that requires our assistance, please forward your ticket ID to qa .at. arvixe.com as well as arvand .at. arvixe.com and we can look into the best way to resolve this.
We're developing a software with Weblogic application server (12.1.1.0); We have one domain with two applications.
We just moved up from development DB to pre-production DB (similar to production), and oh boy we got a major issue going...
DBA says the DBs are running the same version - Oracle 11 (I don't recall the exact version). The only difference we can see is that the dvlp DB uses SID for connection, and the other two uses service-name.
Now, in our domain we have two data sources X and Y. Both are connected to the same DB. We use XA driver on both. Both our applications uses the same 'persistence.xml' (and entities) which has two PUs (persistence units), each using a different data source (X and Y).
The problem is this:
An MDB starts handling a request.
It uses both PUs with EntityManagers and the Y data source with DataSource interface, which is used to get a connection (we have some JDBC code).
It calls a bean from the other application.
The other bean tries to use one of the PUs (the one connected to X data source).
SQLException is thrown:
XA error: XAResource.XAER_NOTA start() failed on resource 'x_my_domain': XAER_NOTA : The XID is not valid
We've searched the error online and we found out that we should change the data sources' configuration to
XASetTransactionTimeout=true
XATransactionTimeout=0
but that didn't worked.
We've also tried (a lot) to tweak the data sources' configuration, eventually removing one of them so we only need to tweak with only one of them, but nothing has worked.
In addition, while repeatedly tweaking the configuration, a different SQLException has slipped under our radar and started popping out instead of the previous:
Internal error: Cannot obtain XAConnection weblogic.common.resourcepool.ResourceDisabledException: Pool X is Suspended, cannot allocate resources to applications
Now this one is even more frustrating, because we tried everything; reset the data source; delete and re-create; delete and re-create with different name; delete the domain and re-create with a different data source name; go back using the dvlp DB; but nothing, the exception seems to persist.
We really don't have any idea of how to solve this and we can't go any further without fixing this problem.
We finally found how to fix the problem, but to answer the question I will have to explain more about our environment; We actually have two managed servers, and each application runs on another server. Both the admin-server and one of the MS runs on one machine, and the other MS runs on another machine (total of two machines).
The thing was that when we modified one of the data sources (X), which was used also by the other MS, we didn't restarted the other MS, but only the data-source. We guess that this caused the data-source not to update with the new modifications on the other MS, which caused the errors we encountered.
The problem was caused by a rather foolish reason, but it was hard to spot because it recurred on any environment setup of the admin-server + first MS part, even on our own PCs with a setup of only an admin-server with no definition of machines. The reason it still happened is because the address of the machine containing the other application was written in the code (read from XML configuration, but that doesn't change much).
Well, glad that's over with.