Re: SQL Losing Data

From: Sue Hoegemeier (Sue_H_at_nomail.please)
Date: 01/14/05 

Date: Fri, 14 Jan 2005 10:38:55 -0700

Actually not really. I still think you are missing the
point. You often have to do the same thing with other data
sources that support timestamps when using ODBC linked
tables and Access. You have to kluge the data source so that
Access doesn't get confused. You can find more information
in the following Access KB article:
ACC2000: Optimizing for Client/Server Performance
http://support.microsoft.com/?id=208858
The point being, that if you convince yourself that these
are all SQL Server issues or bugs then that's probably the
only place you will look to for solutions. In the first
case, you would not have found the answer searching SQL
Server issues. You'd find the answer under Access and ODBC.
If you leave yourself convinced that the users edit records
on an Access form and the changes aren't saved so it must be
a SQL Server issue, you may not find the answer to the
problem or you may end up wasting a lot of time.
Keep in mind that you posted earlier that:
>there are three subforms in the middle of the main form. All main
>form fields above the subform, as well as the subform data itself, are being
>saved. It's only the fields below the subform that are being lost.

In terms of Profiler, you can filter the trace to your
access application to limit the results. With bound forms,
the commands would show up under the RPC and SP event
classes. In addition, there is a lot of information on using
profiler in SQL Server books online.

The other resource you may find useful overall is to get a
copy of Microsoft Access Developers Guide to SQL Server by
Mary Chipman and Andy Baron. It's an excellent book.

-Sue

On Fri, 14 Jan 2005 06:32:56 GMT, "Neil Ginsberg"
<nrg@nrgconsult.com> wrote:

>My guess for the culprit would be the ODBC driver, as I've seen it do some
>funky things over the years, this last situation being one of them. And, in
>this last situation, though it wasn't SQL Server's fault, per se, but,
>rather how the ODBC driver interfaced with SQL Server, the end result was
>that there was a configuration issue on the SQL end (timestamp fields)
>needed to get the ODBC driver to behave correctly. That's what I'm talking
>about.

Relevant Pages

  • Re: SQL Losing Data
    ... I never said it was a SQL Server ... ODBC driver isn't sending it there for some reason, ... >>form fields above the subform, as well as the subform data itself, are ... lost," I wasn't saying that Access was saving some fields but not others; ...
    (microsoft.public.sqlserver.odbc)
  • Re: SQL Losing Data
    ... the other problem wasn't a SQL Server thing. ... And I would argue that it was an ODBC driver issue, solely, not even Access. ... sidebar shows a pencil, indicating that edits are being performed. ... I've tried using Profiler in the past and found it a bit unwieldy. ...
    (microsoft.public.sqlserver.odbc)
  • Re: SQL Server 2005 "Left outer join" return nothing through ODBC call
    ... Some outer joins suddenly returned empty resultsets on SqlServer 2005 in 2000-compatibility-mode, but only within our application. ... The same query executed in Query Analyzer just worked fine. ... We finally solved that issue by upgrading to the latest SqlServer ODBC driver which can be found at: ... It did work for SQL Server 7.0 and SQL server 2000. ...
    (microsoft.public.sqlserver.odbc)
  • Re: localized ODBC driver datetime issue
    ... which I use to connect to MS SQL Server 2003. ... SS> format, because this format does not correspond to the Russian date ... SS> was a way to know the language used by the ODBC driver, ...
    (microsoft.public.data.odbc)
  • Re: dts retrieves 0 rows when scheduled...
    ... Have you tried logging in as the SQLAgent service account and running the ... job/checking out the ODBC driver? ... > There is no error massage i can trace in sql server or in any of its logs, ... > the job just passes gracefully by the dts data transfare tasks, ...
    (microsoft.public.sqlserver.dts)