August 29, 2012 at 3:07 pm
My app includes
1) SS2K8 database on the back end
2) Access 2007 front end NOT LINKED, data flows through ADO and stored procedures on the back end.
=================
Front End consists of forms/subforms and proxy tables "connected' to subforms.
Data flows that way:
Sql server table <===> Access proxy table <===> subform
==============
Now a fun part begins:
user opens the form (with continuous subforms populated with items) and just sits back doing nothing. Then suddenly records disappear from the subform with scary "=deleted" on the items a second ago having meaningful data. Can you imagine how happy the user can be?
I checked the underlying table - empty
==================
After reloading the Access form all data comes back (SQL Server table was not changed)
What? Why? No idea
Val
August 29, 2012 at 3:28 pm
That's quite an unusual design approach to creating a front-end to SQL Server. In general the recommendation is to either use an ADP front-end, although support in future versions is questionable, or to link the SQL Server tables using ODBC. Several questions:
What format is your Access front-end - accdb or mdb?
How are your main and subforms linked?
Also are both the main form and the subforms linked to the proxy table? If so it sounds like the proxy table is being cleared by something.
Is this an existing application that has been running for some time or is it a new one?
Wendell
Evergreen, CO
Wendell
Colorful Colorado
You can't see the view if you don't climb the mountain!
August 29, 2012 at 4:13 pm
ok.
1. This is mdb
2. Subform are just imbedded into main form
3. Only subform is linked to the proxy table (because the table feeds continuous subfom) Other controls (dropdowns, textboxes) do not need a proxy table and are populated directly from SQL Server
4. It is a new application. During testing we did not see that problem.
================================
I just tried this:
a. I open an instance of the mdb on ONE computer. Data on subform is ok - not deleted.
b. I opened 2 instances of the same mdb file on 2 different computers. It takes 15 - 40 sec for the data on subform of the first computer to loose the data, the second computer subform stable.
c. I copied the mdb to two different locations, and opened each of them on two different computers. No problem at all, subforms behave!
Hence: two instances of the same mdb somehow (I do not know!!) communicate with each other and kicks the data out of each others proxy tables.
(F. Chopin, Funeral march ...)
August 29, 2012 at 5:01 pm
Well, I'm afraid I'm not much help at this stage. I've not worked with "proxy tables" at all either in Access or SQL Server - from web research they appear to used primarily with SyBase rather than SQL Server. But the fact that you are able to get to work on some PCs but not on others suggests to me that either the network connection to one or more of the PCs is flakey, or that you have software differences in what used to be called the MDAC package. Are all workstations running the same OS, and do they all have SP3 for Office 2007?
Wendell
Colorful Colorado
You can't see the view if you don't climb the mountain!
August 29, 2012 at 6:01 pm
Hi Val
To understand your problem I need clarification on a couple of things. I have experienced linked tables causing forms to display #Deleted, but not the data disappearing from the form. The #Deleted is well documented on the net and generally relates to keys/indexes.
Firstly, what exactly do you mean by a proxy table? Are these just links to SQL Server created using ODBC or some form of (pass-through) query?
Secondly, do you users access a common fron end or do they all have seperate copies? I guess what I'm getting at here is if they are all using the same front-end, then one user may be upseting the data source of another. If you are using ODBC links this will be unlikely.
Cheers
Rowan
August 30, 2012 at 6:44 am
Rowan:
==> Firstly, what exactly do you mean by a proxy table? Are these just links to SQL Server created using ODBC or some form of (pass-through) query?
=====
There is no LINKED tables in this Access front end app. There is no pass-through queries. SQL stored procedure called from Access (by ADO connection/command) would open a recordset that populates local ("proxy") Access table that is linked to continuous subform.
==> Secondly, do you users access a common fron end or do they all have seperate copies? I guess what I'm getting at here is if they are all using the same front-end, then one user may be upseting the data source of another. If you are using ODBC links this will be unlikely.
====
Users are using ONE Access file from the share drive to open an instance of it on their computers.
Question regarding ODBC linked tables: When I try this I can only READ the data, not WRITE. Is it possible to do both on linked tables?
August 30, 2012 at 7:14 am
Regarding your question about linked tables, and whether they can be written to, absolutely yes. We have a number of systems deployed that used linked tables that are updateable. In fact, we also link to views which are updateable. ODBC linked tables are the preferred method for using an Access front-end to SQL Server tables per Microsoft. If you are seeing the tables as read-only, chances are your userID in SQL Server doesn't have permissions to edit or append data.
And regarding the shared front-end, that is generally considered dangerous. We always deploy the front-end to the user PC - that way if the front-end is somehow corrupted, we can simply replace the one on the PC. Otherwise, you have to get everyone out of the system so you can repair whatever has gone wrong. We learned that the hard way with some 80 PCs trying to share a front-end. It was a disaster, and we quickly changed to copying the front-end to the PC. That was in 1994. I think you will find that concept in nearly every best practice - if you want a bit more detail take a look at http://www.access-experts.com/default.aspx?selection=TutorialSplitDB&sm=18
Wendell
Evergreen, CO
Wendell
Colorful Colorado
You can't see the view if you don't climb the mountain!
August 30, 2012 at 9:01 am
Thanks.
==> If you are seeing the tables as read-only, chances are your userID in SQL Server doesn't have permissions to edit or append data.
But there is no problem for me to get to SQL Server through current Acces front end. May be there is something that I need to change on the Access side? permissions on each table, or else? Please give me more practical details
===========
==> And regarding the shared front-end, that is generally considered dangerous. We always deploy the front-end to the user PC - that way if the front-end is somehow corrupted, we can simply replace the one on the PC.
Yes. That's what we found as well. Or create folders for each user (we have only 4, but all of them are VIPs, e.g. hysterical 🙂 on the share drive so they could enjoy there own file - in this case we do not need to go to each computer: just substitue old files with a new one
Thanks again
August 30, 2012 at 9:43 am
valeryk2000 (8/30/2012)
Thanks.==> If you are seeing the tables as read-only, chances are your userID in SQL Server doesn't have permissions to edit or append data.
But there is no problem for me to get to SQL Server through current Acces front end. May be there is something that I need to change on the Access side? permissions on each table, or else? Please give me more practical details
===========
In order to connect to SQL Server tables you must specify a specific login name - either SQL Server based, or Integrated Security (which I much prefer). Any user who wants to be able to edit data in a table must either be given explicit permission on that table, or they must belong to a group that has that ability. One solution we use is to make them a member of the dbOwner group, but that does have some downsides, as they can do pretty much anything they want to the entire database.
On the Access side, unless you activate Access User Security, there is no permissions to set. (By default you connect as "Admin" and that user can do anything they want to the database.) However, the SQL Server table must have a primary key set if you link to it and want to edit it. Otherwise, Access treats it as read-only. The same is true of local tables (including temporary ones) unless you explicity create a primary key when you create them.
Hope that helps.
Wendell
Evergreen, CO
Wendell
Colorful Colorado
You can't see the view if you don't climb the mountain!
August 30, 2012 at 9:49 am
OK. Let me try it
Thanks a lot
August 30, 2012 at 8:50 pm
With all the previous post it sounds like you are well underway with a solution - many people using one MDB would have been the cause of your data display issues as each new user would have been changing the recordsets of the previous.
But just in case, I thought I would expand a little on the method of connecting of Access to SQL Server.
1) Set up an AD group and assign to it the users who are to access this database. This enables the use of Windows Authentication as a security method rather than SQL Server;
2) Create an AD login for this group in SQL Server, mapping the login to your user database and maybe tempdb (for the benefit of your stored procedures).;
3) Grant appropriate permissions to the objects in the database eg tables will need select, insert, update and delete; stored procedures will require exec. You can do this manually if you only have a few objects, or write some SQl to do it for you - maybe keep it as a stored proc.
You can either continue to use the existing ADO methods in Access or convert to using ODBC and linking the tables. If you use ODBC you will need to set up a connection (using the ODBC administrator) on all PCs designated for access to the app.
All the best.
August 31, 2012 at 1:16 am
I frequently use this technique and never encountered this kind of problem. The sole difference is that I use DAO insead of ADODB as data library.
Note: ADP is not supported in the recent versions of MS Access (2007 and beyond).
August 31, 2012 at 6:58 am
rf44 (8/31/2012)
...Note: ADP is not supported in the recent versions of MS Access (2007 and beyond).
Actually, ADP is supported in Access 2007 and 2010 (see for examplehttp://social.msdn.microsoft.com/Forums/en-US/accessdev/thread/795d5b36-6d8e-43e2-9d17-1a168c197adb), but rumor has it that it will not be in the next version - see http://answers.microsoft.com/en-us/office/forum/office_home-access/access-2013-no-support-for-access-project-adp/762fcedf-fdca-4b18-a918-850646897dda?tab=AllReplies&page=1. Microsoft put out the word that it would not be enhanced some time ago, so the handwriting has been on the wall, but some people apparently weren't listening.
Wendell
Evergreen, CO
Wendell
Colorful Colorado
You can't see the view if you don't climb the mountain!
August 31, 2012 at 7:37 am
1) Set up an AD group and assign to it the users who are to access this database. This enables the use of Windows Authentication as a security method rather than SQL Server;
2) Create an AD login for this group in SQL Server, mapping the login to your user database and maybe tempdb (for the benefit of your stored procedures).;
3) Grant appropriate permissions to the objects in the database eg tables will need select, insert, update and delete; stored procedures will require exec. You can do this manually if you only have a few objects, or write some SQl to do it for you - maybe keep it as a stored proc.
==> actually I've done all that (1,2 and 3)
You can either continue to use the existing ADO methods in Access or convert to using ODBC and linking the tables. If you use ODBC you will need to set up a connection (using the ODBC administrator) on all PCs designated for access to the app.
My serious (but may be naive) concern about linked tables: in a "simple" Access app form controls are linked to tables (or through queries) by DYNASET, that would change table field value every time you change it in the control. Our current design (SQL Server / ADO) allows to update the record ONLY by firing event on the Access front end form (e.g. clicking button "Save Changes"). Am I wrong?
August 31, 2012 at 7:49 am
Another question (not related to the topic, or ... related?). When we load nvarchar (max) - a.k.a. memo into Access form text box or report field it is truncated. To overcome this problem we cast navarchar(max) as Text (just to remind, SQL Server Text datatype, not Access). Does anybody have better solution (keeping in mind that TEXT datatype is obsolete in SQL version after 2008)?
Viewing 15 posts - 1 through 15 (of 29 total)
You must be logged in to reply to this topic. Login to reply