August 31, 2012 at 7:52 am
And one more: what is the best way dealing with "=deleted' on subform?
August 31, 2012 at 8:12 am
valeryk2000 (8/31/2012)
....
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?
Actually, the change to the data in the underlying table in a bound (linked) form only changes when the Update event fires at the form level. Prior to that the data in the control changes, but the changes are not committed to the tables until the form is either closed or you move to a new record. Any changes to the current record can be cancelled by the user hitting the ESC key twice. If you choose to use an unbound form then you need to have ADO or DAO code that populates the controls on the form, and that saves any changes when the user clicks a "SAVE" button or some other suitable event occurs. The unbound form approach is appropriate in certain situations, such as a data entry form that requires storing data in numerous related tables, but the coding cost to create such forms, and the maintenance cost when changes are required, results in us using bound forms most of the time.
Wendell
Colorful Colorado
You can't see the view if you don't climb the mountain!
August 31, 2012 at 8:27 am
valeryk2000 (8/31/2012)
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)?
The truncation of "memo" type data in Access has been a pain since day one. Most often, the reason is that the recordset is being sorted in some way in Access, and it is most often an issue in continuous forms. Is there an explicit reason for using nvarchar rather than varchar? UniCode is great if you need to store information in languages other than the "Latin" language set, but it requires twice as much space. If you are storing long documents, then the (max) parameter would be necessary, but otherwise the maximum of 8000 characters will suit most needs. If we get something larger than that, the ususal approach is to save the data as an object rather than as text data - larger documents typically contain formatting and other information that can't be stored in a raw text field. Bottom line - if you can avoid sorting the recordset, I think you will find the Access form behaves OK. If you can't avoid sorting the data, then you may want to resort to a pop-up form to let the user view and edit the data.
Wendell
Colorful Colorado
You can't see the view if you don't climb the mountain!
August 31, 2012 at 8:32 am
valeryk2000 (8/31/2012)
And one more: what is the best way dealing with "=deleted' on subform?
Unfortunately, I don't know of anything that can be done when that happens. But that only happens on bound forms, which is to say that if you used an unbound form, that wouldn't happen. But as I noted in a previos response, subforms are almost impossible to do in a continuous unbound form. What that means is that the underlying data on the form has changed, and you shouldn't be seeing that if each user has their own copy of the database that they run.
Wendell
Colorful Colorado
You can't see the view if you don't climb the mountain!
August 31, 2012 at 8:36 am
There is a known problem with Access linked to a SQL back end that can exhibit this behaviour.
If you have a bit column in the table that does not have a default value, Access will struggle.
Check the definitions for your tables - set the default value of any bit fields to 0, then update the table(s) to set the value of the bit fields to 0 where the current value IS NULL
August 31, 2012 at 10:51 am
May be just make the form invisible before it can be requeried?
September 1, 2012 at 2:19 pm
The challenge in doing that is to know that the subform controls are displaying "=deleted" - it's not something I've ever attempted. If you can do that then you could hide the subform control until it has been populated. But that text popping up doesn't trigger an event as far as I know, so there's the problem. You could certainly try putting a bit a code behind the "Before Del Confirm", "On Delete", and "After Del Confirm" to display a simple text box message, but I don't think it will work. I presume you have solved the situation where multiple users were sharing the same database and clobbering the temporary table.
Chris makes an excellent point - with SQL Server tables you want to make sure that the have a default value defined for bit fields, or you will have all sorts of trouble. Another thing you should also do is to give each linked table a TimeStamp field. Access is much happier when you do that - if you don't you tend to get ODBC error messages that another user has edited the record, and your changes cannot be saved.
Wendell
Wendell
Colorful Colorado
You can't see the view if you don't climb the mountain!
September 1, 2012 at 2:26 pm
I'll try. Users now use different files. The only case "=deleted " shows up - when user switches to another case and the subform is reloaded.
Thanks
September 1, 2012 at 2:50 pm
That is an easier case then as you know you are getting new data, so you can hide the subform control (set the visible property to No), get the data, and then unhide it by setting the Visible property to Yes.
Afterthought - just out of curiosity can you give us a brief idea of what your application is for?
Wendell
Wendell
Colorful Colorado
You can't see the view if you don't climb the mountain!
September 1, 2012 at 11:54 pm
Hi
When you say "=deleted" do you mean "#deleted"?
If you do then I think you have an issue with the primary key on one or more of your tables. One of the common causes of this is the use of the bigint data type for your primary key.
Cheers
September 2, 2012 at 6:50 am
Afterthought - just out of curiosity can you give us a brief idea of what your application is for?
Wendell
This is an application with sensitive patient and doctor information. They created an Access database 4 years ago and were constantly updating since then. It has a lot of forms, subforms, reports and subreports. At some moment it occured to the management that the data is not safe in Access. So they told me to transfer the data to SQL Server ... but keep the Access front end intact (I tried to suggest that VB, Java or Web front end would be much better - no way, management was very conservative). SQL statements on the front end would use real table names (as well as linked tables app) with a posibility to read or affect a back end data by a "unauthorized user". So I moved all logics (select, update, delete, etc) to the back end in stored procedures and triggers.
This is a sad story in short
condolences are accepted around the clock 24/7 🙁
Thanks
September 3, 2012 at 7:09 am
I should say! Extended condolences are definitely in order. :crying:
There's a common misperception that Access is an insecure system that is also unreliable. As long as you use the .mdb format, you have Access User Security. That feature can be used to manage what various users are permitted to see and do. If you are using an Access back-end for data storage, then there are issues with reliability and with the possibility of theft or loss of the data. But once you put that data into SQL Server on a physically secured server, then an Access front-end provides the fastest development path to a feature rich user interface. With a compiled and properly secured front-end your data is as secure as with any other system.
My prescription for a frazzled and frustrated developer would be a nice long holiday weekend like we are having here, but on a beach or along a quiet mountain brook. (Bad planning on our part to be cutting over a new client this weekend. :crazy:) Hopefully your situation is beginning to settle down and behave as it should, and things will get better.
Wendell
Evergreen, CO
Wendell
Colorful Colorado
You can't see the view if you don't climb the mountain!
September 3, 2012 at 10:50 am
With a compiled and properly secured front-end your data is as secure as with any other system.
Compiled - is a key word. Our current wersion is not compiled - simple mdb. That's why all logics is hidden in SQL stored procedures that are called from the front end
==================
Thank you. We have a lot of rain on the East Coast of the country. So ... I enjoy fixing holes in my apps
September 3, 2012 at 10:52 am
When you say "=deleted" do you mean "#deleted"?
Certainly "#deleted". Thank you
October 31, 2012 at 4:17 pm
WendellB (9/3/2012)
There's a common misperception that Access is an insecure system that is also unreliable. As long as you use the .mdb format, you have Access User Security.Wendell
Evergreen, CO
ah, i have a file..no installation require that I use to get mdb passwords...sorry but its security is crap.
I have a pretty good security procedure working for me right now with them though...anyways...this topic is not abt security...
to the original poster...i noticed your first post is that the user sits and does nothing then suddenly its "=deleted"
i think your connection timed out.
Viewing 15 posts - 16 through 29 (of 29 total)
You must be logged in to reply to this topic. Login to reply