I have QGIS 3.4 Madeira LTR connected to my Microsoft SQL Server Management Studio 17. I have a lot of data on the SQL Server and since the start of the new year I can't edit my layers in QGIS anymore. I can load the data but it doesn't visualize and I can't zoom on the Layer Extent (In Options it says Extent=Empty but thats not true, because I checked the tables on the Server and they are structured like before). The weird thing is, when I load a layer from my harddrive everything works just fine. The loaded layers from my SQL Server show up but I can't open the attribute table or select features. In some cases Im able to open the attribute table but it only shows one entry (no filters activated). I was thinking that something is wrong with the geometry or the CRS but I did not update the software or change anything in the SQL tables. QGIS even crashes when trying to open attribute tables. It gave me the option "try to repair the map document" but after trying it the connected SQL Table disappeared on the Server but is still visible in the MSSQL dropdown menu on the left (but the data on the SQL Server is definitely gone). Also weird is that saved map documents show the data when I open them but when I add a new SQL layer the data doesn't show up. I would really appreciate some help.
I checked the SQL tables if maybe some primary keys were missing or the geometry column. I checked my update history but nothing was updated. I'm a bit lost where to start and scared to lose more of my data.
I have gotten oracle database to connect to an excel spreadsheet except for 1 issue -- the excel table is not properly refreshing (i.e. a row I deleted in oracle still shows up in excel version). How is this happening? I cannot figure out how to get it to reflect the current version of the database without making a new spreadsheet and reconnecting. Even if I clear the table, My refresh data button brings back those rows that don't exist anymore
Also, I want to make a user-friendly way to add or delete rows in oracle via excel spreadsheet. So whatever I do in excel would automatically update in the oracle database. Is this even possible or am I really overreaching?
Does anyone have any ideas or tips? I'm not very technical so please dumb down any responses
I currently have a backend database using Microsoft SQL Server, and I am building a frontend interface with Microsoft Access. Access interacts with the backend by way of pass-through queries, so all of the SQL statements are collected by forms, constructed in VBA, and then sent to the server directly. This is because of network latency issues, and my understanding is that Access is inefficient when using linked tables and if it has to translate Access queries into T-SQL queries.
I now need to make a form that SELECTs from the database, updates one or multipe records/fields, and then UPDATEs the database. Is it most efficient to:
Update each record individually with its own query (the user would have to click a "Save" button or something
Load the table into a Recordset object, make the changes locally, and then send one query to the server to batch update. I could either make the changes in VBA or attach the Recordset to the form and let Access handle the updating of the Recordset
In the latter case, if an update is made to a Recordset object, will Access automatically write to the SQL server if the recordset is populated with a QueryDef in VBA code?
I have an mdb which used to contain a bunch of linked tables. These links point to tables in another Access mdb.
As part of a controlled migration, I'm changing these link table to point to an SQL server instance instead, by iterating through all linked tables and updating the connect string to an ODBC one, then calling RefreshLink on the tabledef.
However, on opening my new database with ODBC links, Access crashes. More interestingly, if I remove a single specific linked table (via ADO) I can then open up the database. Even more interestingly, if I add that linked table back in through the Access GUI, it doesn't crash, so I know it's not a problem with the table itself in SQL Server.
So, I need to figure out what it is about this particular linked table that causes Access to crash. Can I get at any kind of information about the crash to help? Where can I even start investigating this?
EDIT: I have tried a number of ways of refreshing the link table, either by Refresh Link, or dropping and recreating the tables with DSN or without DSN, etc. Every time it is the same table that causes the mdb to crash on opening.
EDIT 2: Sadly it seems that the crash is actually in some way down to source control - if I disable my SCCAPI provider then there's no crash. I still have no idea how to investigate this.
Delete the links and create entirely new ones. ODBC links cannot be reliably refreshed even when they start out as ODBC links.
No strategy for linking tables changed the results, we would still get the same crash in the same database because of the same table.
However, disabling source code control fixed the issue, and nobody has suggested a possible reason for that, nor a method of investigating, so I'm closing the question by accepting "Disable SCC" as an answer.
I use MySQL linked tables a lot in my Access databases though any writing I do an ADO connection not the ODBC.
However recently in a new project I linked to a new database - a web backend MySQL - linking was fine - test connection was fine - but 1 particular table linked fine but try and open it - MS Access was instantly obliterated - something I have never seen in any of my databases using ODBC linking.
The beauty of ODBC linking is it uses DAO not ADO and you can treat the table as a local table - not to be even ADO on this particular table errored - but did not give an error code to help.
Solved the problem - this table had 2 fields in type JSON (which is really only Long Text) but Access was killed - even with the latest driver 8.0
Luckily am in contact with web developer and this was a bespoke database but the JSON fields were not being used - so he converted them to Long Text - voila - MS Access was perfectly happy again.
Though the annoying thing I haven't solved is linked tables show contents as #DELETED# - and a F5 refresh is necessary to populate - though with driver 8.0 this is not working.
However, ADO is happy and a copy and paste link as a local table works perfectly.
I have managed to get SQL Server 2005 Express up and running on my computer Ok in order to do some testing before trying this in the "Real World".
I have a fairly large MS Access 2007 Database application I need to migrate to SQL Server
retaining the "Front End" as the user interface. (The app' is already a "split" database
with a Front and Back end....)
I have done some initial testing on using SSMA to migrate my Access database To SQL
Server Express.
Clearly I don't understand some things and I thought I'd see if anyone has
any ideas.
Conceptually I thought that what needed to happen was that the Back End of the
database that resides on the server needed to be migrated to SQL server
and then the Front End re linked to the (now linked to SQL) tables in the Back End.
When I do this using SSMA I end up with renamed tables in the Back End
Access file that look something like "SSMA$myTableNameHere$local". I also
get the original table names underneath showing as ODBC linked tables.
So far so good.
BUT.... When I go to re-establish the linked tables from the FRONT END (The
user interface) all I can see is the "SSMA$myTableNameHere$local" names NOT
the original table names.(Now linked via ODBC)
I can link to the "SSMA,,,," tables but it would mean changing the names of
every table in every query and on every form and in all code on the Front
End! Not something I really want to do.
SO....
I thought I'd try to migrate the FRONT END and see what happens.
What I ended up with is a situation where, basically it works (there are
some serious errors and issues that I haven't even looked at yet... like
missing data etc.!!!!) and I still get the "SSMA$myTableNameHere$local"
tables and the ODBC linked tables with the original names.
I'm trying to understand...... Does this mean that we would do the
migration on the Front End and then just copy the same file to each user's
computer?
Another subject I'm a little confused about is that I can't link via ODBC
to SQL Server Express on the local machine (ie my computer) so I can't test
migrating the Back End and then linking to the tables via the Front End as I
have in the past in more of a client/server situation.
Assuming that SSMA replaces the tables in your back end with links to the SQL Server, all you need to do is delete the original table links in your front end and import the newly-created table links from the back end. You can then discard the back end, since it's not used for anything at all any longer.
I did transfer all my tables one by one to SQL Server 2005 fro Access DB back-end using ODBC.Instruction:
Open Access DB(back-end)
Right-click on table, you need to transfer
Scroll down drop-down box and select ODBC Databases
Select Data Source dialog box opened, Click "New" button
Create new data source dialog box opened
Scroll to the bottom and select SQL Server, Click Next
Give name to your Data Source, Click Next, Click Finish
Create New Data Source Dialog opens
Give some discription OR leave empty, Type Name of your SQL Server (you named it, when install SQL Server on your machine)
Click Next, Click Next
Check "change default database to check box
Select DB where you want your data transfer to
Click Next, Click Finish
NOTE: You need to create new DB (empty) on SQL Server, before doing all this
Now: Right-click any table, select Export, select from drop-down list ODBC, from Data Sources window select your Data Source, You created, Click OK
Use SQL Server with SQL Management Studio Express.
All dates must have a input mask; all text and Memo must have Allow Zero Length =Yes
After all disconnect all links from Access back-end, and establish links from SQL.RENAME all newly linked tables to old names. Use Fron-end user interfase, until do some new.
Forgive my lack of knowledge of Acronym Soup, but I assume SSMA is the SQL Server 2005 "import data wizard" or the wizard in Access to send the data to SQL Server. It appears that you sent the data to SQL Server from Access - something you don't want to do. You want to use the DTS in SQL Server (now called SSIS or something?) to import the data into SQL Server. Then you'll have your tables in SQL Server. Then, simply create your DSN entry for the SQL Server and re-link your tables. All should be well.
Overall, the general rule is to import Access tables using SQL Server instead of using Access to send the data to SQL Server.
I'd bite the bullet and rename the tables on the SQLServer side back to the friendly names that you had in the original database. You'll probably have less problems. Especially if you have any embedded code the MS Access side.
As far as how you will deploy the MS Access side now, it should be pretty much create the ODBC link on the user's workstation, and copy the MS Access file to their desktop (although you might want to make an MDE (or the 2007 equivalent) to prevent them from accidentally breaking it).
Frankly, now that you have migrated, you need to look at the design of your tables. It is my experience that the wizards for Access migration do a poor job of selecting the correct datatype. For instance if you had a memo field, you might easily get away with a varchar field instead but the last wizard I used (an earlier version) always converted them to text fields. Now would also be the time consider some fixes such as making date fileds datetime instead of character based if you have had that mistake in the past.
I would never consider using a wizard again to do data migration myself having experienced how very badly they can do it.
You will alos find that just converting the data to SQL Server is often not eough to really get any performance benefit. YOu will need to test all the queries and consider if you can convert them to stored procs instead if they are slow. Eliminating the translation from Jet SQL to T-sql can being performance improvements. Plus there are many features of t-sql that can imporve performance that do not have Access equivalents. Access is not big on performance tuning, but to get the benefit of performance tuning with a SQL Server backend, you need to have SQL Server specific queries written. INdexing needs to be considered if the Access tables were not indexed properly.
Using SSMA is different when you use odbc. If you have an application using fully access (back end and front end). You can manipulate objects easily bounding forms, using DAO, etc.. without problem, then when u need to migrate database to sql server u can use directly odbc (by linking yourself tables to sql server), ssma, ... the main problem how to preserve bounded forms, queries, code in the client-side.
If U use directly odbc you must relink by yourself all objects and change code but if u use ssma, you have to do nothing, you will continue to work as u did before. The problem with SSMA is how to deploy the front end to the clients if you developed client side in other place using another sql server?