Offline use

Hi
We have an access app (both front & back ends are in access) that runs over
win server networks. There are now more and more users who would like to
take away a copy of app with them, work offline, and when they come back
expect the client copy to sync (both ways) with the server copy. Seems like
a reasonable requirement. The question is; what do I need to do to make this
happen? Do I need to switch the backend to sql server? Front end to vb or
something like that? Anything else? How do other people do this?
Thanks
Regardsuse merge replication to MSDE databases, create pull subscriptions
managed by Windows Synchronization Manager.
--
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com|||Is this reliable "enough"?
Regards
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:1114135809.601906.238980@.o13g2000cwo.googlegroups.com...
> use merge replication to MSDE databases, create pull subscriptions
> managed by Windows Synchronization Manager.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>|||Hi
If architected correclty, it works perfectly.
But, considering it is offline, there is always a small chance that you
loose data. The device can be lost or fail before you have the opportunity
upload the data. If you need 100% guarantee that the data gets to your DB,
you have to do it online.
Regards
Mike
"John" wrote:
> Is this reliable "enough"?
> Regards
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:1114135809.601906.238980@.o13g2000cwo.googlegroups.com...
> > use merge replication to MSDE databases, create pull subscriptions
> > managed by Windows Synchronization Manager.
> >
> > --
> > Hilary Cotter
> > Looking for a SQL Server replication book?
> > http://www.nwsu.com/0974973602.html
> >
> > Looking for a FAQ on Indexing Services/SQL FTS
> > http://www.indexserverfaq.com
> >
>
>|||> Is this reliable "enough"?
Compared to using Access Jet in a shared environment? Almost certainly!
--
David Portas
SQL Server MVP
--|||Yes, Kratft Foods/Nabisco has a solution using this only to hand helds
running SQL CE with IIRC 1400 truck drivers. Their fleet distribution
network is built on this. Its reliable enough for them.
--
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"John" <John@.nospam.infovis.co.uk> wrote in message
news:u%23eUINxRFHA.3972@.TK2MSFTNGP14.phx.gbl...
> Is this reliable "enough"?
> Regards
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:1114135809.601906.238980@.o13g2000cwo.googlegroups.com...
>> use merge replication to MSDE databases, create pull subscriptions
>> managed by Windows Synchronization Manager.
>> --
>> Hilary Cotter
>> Looking for a SQL Server replication book?
>> http://www.nwsu.com/0974973602.html
>> Looking for a FAQ on Indexing Services/SQL FTS
>> http://www.indexserverfaq.com
>|||I'd move to a SQL server (or MSDE) and .Net solution.
ADO.Net (the data access part of .Net) is already disconnected. Data
is moved back and forth between the client and server (even if they're
running on the same machine), in the form of disconnected datasets.
Datasets can be persisted to XML files.
This is one of the cool features of the .Net platform and is really
worth looking into for your needs.
-nick
On Fri, 22 Apr 2005 01:15:39 +0100, "John" <John@.nospam.infovis.co.uk>
wrote:
>Hi
>We have an access app (both front & back ends are in access) that runs over
>win server networks. There are now more and more users who would like to
>take away a copy of app with them, work offline, and when they come back
>expect the client copy to sync (both ways) with the server copy. Seems like
>a reasonable requirement. The question is; what do I need to do to make this
>happen? Do I need to switch the backend to sql server? Front end to vb or
>something like that? Anything else? How do other people do this?
>Thanks
>Regards
>

ODBCJT32.DLL on 64 bit Win 2003 SP1 & Yukon i64 server

Hello folks,
I have an issue with ODBCJT32.DLL on a Itenium server that Yukon i64 (April
CTP)running on 64 bit Windows 2003 SP1 server. When we try to run a
distributed query that needs this driver SQL gives the following error:
Msg 7403, Level 16, State 1, Line 1
The OLE DB provider "Microsoft.Jet.OLEDB.4.0" has not been registered.
I ran component checker and it found ODBCJT32.DLL as registered to system.
However, I realized that MSJET40.DLL is not registered, didn't see it from
comp checker either. So I tried to install MDAC 2.8 SP8 (KB829558-ia64) but
it returns "There is no need to install this SP because setup has detected
that the system is newer than the update you are applying"
Now, my last card is manually register MSJET40.DLL to system. What do you
think? Any insight would be helpful.
Thanks in advance.
Sunny Jung
Since SQL 2005 is still in beta, you'll want to post this in the Community
Newsgroups:
http://communities.microsoft.com/new...r2005&slcid=us
--Brian
(Please reply to the newsgroups only.)
"SangHunJung" <SangHunJung@.discussions.microsoft.com> wrote in message
news:0270474D-18E6-400F-A5AF-1C3C457A0400@.microsoft.com...
> Hello folks,
> I have an issue with ODBCJT32.DLL on a Itenium server that Yukon i64
> (April
> CTP)running on 64 bit Windows 2003 SP1 server. When we try to run a
> distributed query that needs this driver SQL gives the following error:
> Msg 7403, Level 16, State 1, Line 1
> The OLE DB provider "Microsoft.Jet.OLEDB.4.0" has not been registered.
> I ran component checker and it found ODBCJT32.DLL as registered to system.
> However, I realized that MSJET40.DLL is not registered, didn't see it from
> comp checker either. So I tried to install MDAC 2.8 SP8 (KB829558-ia64)
> but
> it returns "There is no need to install this SP because setup has detected
> that the system is newer than the update you are applying"
> Now, my last card is manually register MSJET40.DLL to system. What do you
> think? Any insight would be helpful.
> Thanks in advance.
> Sunny Jung
>
|||Okay, I posted it there.
However this seems like Win 2003 server 64bit issue. The reason is I don't
see any other ODBC drivers except SQL Native Client and SQL Server.
Normally, when creat a new data source, I would have a list of drivers to
select such as, microsoft excel, access, Fox Pro, etc. I don't see any of
them except two SQL driver. I think this is some thing to do with MDac but
there is no way I can uninstall MDAC and reinstall. Is there any way to do
that?
Thanks,
Sunny
"Brian Lawton" wrote:

> Since SQL 2005 is still in beta, you'll want to post this in the Community
> Newsgroups:
> http://communities.microsoft.com/new...r2005&slcid=us
>
> --
> --Brian
> (Please reply to the newsgroups only.)
>
> "SangHunJung" <SangHunJung@.discussions.microsoft.com> wrote in message
> news:0270474D-18E6-400F-A5AF-1C3C457A0400@.microsoft.com...
>
>
|||Hi
Most of those drivers have not been ported to 64bit, so you won't see them.
All what I've seen is UDB/DB2, Oracle, Sybase and SQL Server 64 bit drivers
for 64 bit Windows.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"SangHunJung" <SangHunJung@.discussions.microsoft.com> wrote in message
news:6C155DA0-52B3-4B82-A5F2-0B949BF64C21@.microsoft.com...[vbcol=seagreen]
> Okay, I posted it there.
> However this seems like Win 2003 server 64bit issue. The reason is I
> don't
> see any other ODBC drivers except SQL Native Client and SQL Server.
> Normally, when creat a new data source, I would have a list of drivers to
> select such as, microsoft excel, access, Fox Pro, etc. I don't see any of
> them except two SQL driver. I think this is some thing to do with MDac
> but
> there is no way I can uninstall MDAC and reinstall. Is there any way to
> do
> that?
> Thanks,
> Sunny
> "Brian Lawton" wrote:
|||Hi Mike,
That is really good to know. I was thinking about that but I could not find
any web-site saying about it. Is there a website that saying that those
drivers are not available to 64 bit except the ones that you listed below?
I have 32bit Windows 2003 and 32bit Yukon, I do have all the ODBC drivers
including Excel and Access on that server. Only different between two
servers are 32bit vs 64 bit.
Thank you in advance.
Sunny Jung
"Mike Epprecht (SQL MVP)" wrote:

> Hi
> Most of those drivers have not been ported to 64bit, so you won't see them.
> All what I've seen is UDB/DB2, Oracle, Sybase and SQL Server 64 bit drivers
> for 64 bit Windows.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "SangHunJung" <SangHunJung@.discussions.microsoft.com> wrote in message
> news:6C155DA0-52B3-4B82-A5F2-0B949BF64C21@.microsoft.com...
>
>

ODBCJT32.DLL on 64 bit Win 2003 SP1 & Yukon i64 server

Hello folks,
I have an issue with ODBCJT32.DLL on a Itenium server that Yukon i64 (April
CTP)running on 64 bit Windows 2003 SP1 server. When we try to run a
distributed query that needs this driver SQL gives the following error:
Msg 7403, Level 16, State 1, Line 1
The OLE DB provider "Microsoft.Jet.OLEDB.4.0" has not been registered.
I ran component checker and it found ODBCJT32.DLL as registered to system.
However, I realized that MSJET40.DLL is not registered, didn't see it from
comp checker either. So I tried to install MDAC 2.8 SP8 (KB829558-ia64) but
it returns "There is no need to install this SP because setup has detected
that the system is newer than the update you are applying"
Now, my last card is manually register MSJET40.DLL to system. What do you
think? Any insight would be helpful.
Thanks in advance.
Sunny JungSince SQL 2005 is still in beta, you'll want to post this in the Community
Newsgroups:
http://communities.microsoft.com/ne...lcid=us

--Brian
(Please reply to the newsgroups only.)
"SangHunJung" <SangHunJung@.discussions.microsoft.com> wrote in message
news:0270474D-18E6-400F-A5AF-1C3C457A0400@.microsoft.com...
> Hello folks,
> I have an issue with ODBCJT32.DLL on a Itenium server that Yukon i64
> (April
> CTP)running on 64 bit Windows 2003 SP1 server. When we try to run a
> distributed query that needs this driver SQL gives the following error:
> Msg 7403, Level 16, State 1, Line 1
> The OLE DB provider "Microsoft.Jet.OLEDB.4.0" has not been registered.
> I ran component checker and it found ODBCJT32.DLL as registered to system.
> However, I realized that MSJET40.DLL is not registered, didn't see it from
> comp checker either. So I tried to install MDAC 2.8 SP8 (KB829558-ia64)
> but
> it returns "There is no need to install this SP because setup has detected
> that the system is newer than the update you are applying"
> Now, my last card is manually register MSJET40.DLL to system. What do you
> think? Any insight would be helpful.
> Thanks in advance.
> Sunny Jung
>|||Okay, I posted it there.
However this seems like Win 2003 server 64bit issue. The reason is I don't
see any other ODBC drivers except SQL Native Client and SQL Server.
Normally, when creat a new data source, I would have a list of drivers to
select such as, microsoft excel, access, Fox Pro, etc. I don't see any of
them except two SQL driver. I think this is some thing to do with MDac but
there is no way I can uninstall MDAC and reinstall. Is there any way to do
that?
Thanks,
Sunny
"Brian Lawton" wrote:

> Since SQL 2005 is still in beta, you'll want to post this in the Community
> Newsgroups:
> http://communities.microsoft.com/ne...lcid=
us
>
> --
> --Brian
> (Please reply to the newsgroups only.)
>
> "SangHunJung" <SangHunJung@.discussions.microsoft.com> wrote in message
> news:0270474D-18E6-400F-A5AF-1C3C457A0400@.microsoft.com...
>
>|||Hi
Most of those drivers have not been ported to 64bit, so you won't see them.
All what I've seen is UDB/DB2, Oracle, Sybase and SQL Server 64 bit drivers
for 64 bit Windows.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"SangHunJung" <SangHunJung@.discussions.microsoft.com> wrote in message
news:6C155DA0-52B3-4B82-A5F2-0B949BF64C21@.microsoft.com...[vbcol=seagreen]
> Okay, I posted it there.
> However this seems like Win 2003 server 64bit issue. The reason is I
> don't
> see any other ODBC drivers except SQL Native Client and SQL Server.
> Normally, when creat a new data source, I would have a list of drivers to
> select such as, microsoft excel, access, Fox Pro, etc. I don't see any of
> them except two SQL driver. I think this is some thing to do with MDac
> but
> there is no way I can uninstall MDAC and reinstall. Is there any way to
> do
> that?
> Thanks,
> Sunny
> "Brian Lawton" wrote:
>|||Hi Mike,
That is really good to know. I was thinking about that but I could not find
any web-site saying about it. Is there a website that saying that those
drivers are not available to 64 bit except the ones that you listed below?
I have 32bit Windows 2003 and 32bit Yukon, I do have all the ODBC drivers
including Excel and Access on that server. Only different between two
servers are 32bit vs 64 bit.
Thank you in advance.
Sunny Jung
"Mike Epprecht (SQL MVP)" wrote:

> Hi
> Most of those drivers have not been ported to 64bit, so you won't see them
.
> All what I've seen is UDB/DB2, Oracle, Sybase and SQL Server 64 bit driver
s
> for 64 bit Windows.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "SangHunJung" <SangHunJung@.discussions.microsoft.com> wrote in message
> news:6C155DA0-52B3-4B82-A5F2-0B949BF64C21@.microsoft.com...
>
>

ODBC--call failed

I have an Access 97 database (using Jet 4.0) connecting to a SQL 2000
via ODBC - the OS is Win XP Pro SP2. When i open a form to display the
records in the linked table they come up fine, but after about 30
seconds it dings and i get the pop up ODBC--call failed. If i close the
form and reopen it, the records are there again, but the connection
drops again in another 30 seconds.
I'm stumped here because my connection does work, it just keeps
dropping.
Any help or ideas would be greatly appreciated.
Thanks!
Vicki
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
What happens if after you open the form, you go to the last
record and then go about and do whatever with the form? Does
the same thing still happen?
ODBC call failed can happen for a lot of different reasons.
A good way to track them down is to turn on ODBC tracing to
look for specific errors. You would want to make sure to
turn it back off after you get the error as it will really
slow things down.
To turn on tracing, go to the ODBC Data Source Administrator
applet and go to the tracing tab. Just click on start
tracing now and note the location for the trace file. After
you hit the error, go back and click on the stop tracing now
button. Then you can go to the trace file and see what other
information you can get out of the trace file.
-Sue
On Thu, 13 Jan 2005 13:19:15 -0800, vespo
<anonymous@.devdex.com> wrote:

>
>I have an Access 97 database (using Jet 4.0) connecting to a SQL 2000
>via ODBC - the OS is Win XP Pro SP2. When i open a form to display the
>records in the linked table they come up fine, but after about 30
>seconds it dings and i get the pop up ODBC--call failed. If i close the
>form and reopen it, the records are there again, but the connection
>drops again in another 30 seconds.
>I'm stumped here because my connection does work, it just keeps
>dropping.
>Any help or ideas would be greatly appreciated.
>Thanks!
>Vicki
>*** Sent via Developersdex http://www.codecomments.com ***
>Don't just participate in USENET...get rewarded for it!
|||Thanks Sue!
That ODBC Trace really helped! It turns out it is an issue with Access
97 where even if you bracket an alias fieldname in a SQL View, it
considers reserved words as reserved words and can't bring them across.
I was trying to enable my client the usage of their old Access 97 forms
and reports by linking to the data i migrated into SQL, so to do that i
had created a view that mimicked their old fields names ("Phone Number",
"Date Updated", etc) and had no problems staying connected when i tried
it on my server (which has Access 2000) but unfortunately my client
isn't ready to upgrade their Access version.
Oddly though -- reports will work in Access 97 using the reserved field
name, it's just the forms and opening the table directly which caused
the ODBC to drop.
Thanks again!
Vicki
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!

ODBC--call failed

I have an Access 97 database (using Jet 4.0) connecting to a SQL 2000
via ODBC - the OS is Win XP Pro SP2. When i open a form to display the
records in the linked table they come up fine, but after about 30
seconds it dings and i get the pop up ODBC--call failed. If i close the
form and reopen it, the records are there again, but the connection
drops again in another 30 seconds.
I'm stumped here because my connection does work, it just keeps
dropping.
Any help or ideas would be greatly appreciated.
Thanks!
Vicki
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!What happens if after you open the form, you go to the last
record and then go about and do whatever with the form? Does
the same thing still happen?
ODBC call failed can happen for a lot of different reasons.
A good way to track them down is to turn on ODBC tracing to
look for specific errors. You would want to make sure to
turn it back off after you get the error as it will really
slow things down.
To turn on tracing, go to the ODBC Data Source Administrator
applet and go to the tracing tab. Just click on start
tracing now and note the location for the trace file. After
you hit the error, go back and click on the stop tracing now
button. Then you can go to the trace file and see what other
information you can get out of the trace file.
-Sue
On Thu, 13 Jan 2005 13:19:15 -0800, vespo
<anonymous@.devdex.com> wrote:

>
>I have an Access 97 database (using Jet 4.0) connecting to a SQL 2000
>via ODBC - the OS is Win XP Pro SP2. When i open a form to display the
>records in the linked table they come up fine, but after about 30
>seconds it dings and i get the pop up ODBC--call failed. If i close the
>form and reopen it, the records are there again, but the connection
>drops again in another 30 seconds.
>I'm stumped here because my connection does work, it just keeps
>dropping.
>Any help or ideas would be greatly appreciated.
>Thanks!
>Vicki
>*** Sent via Developersdex http://www.codecomments.com ***
>Don't just participate in USENET...get rewarded for it!|||Thanks Sue!
That ODBC Trace really helped! It turns out it is an issue with Access
97 where even if you bracket an alias fieldname in a SQL View, it
considers reserved words as reserved words and can't bring them across.
I was trying to enable my client the usage of their old Access 97 forms
and reports by linking to the data i migrated into SQL, so to do that i
had created a view that mimicked their old fields names ("Phone Number",
"Date Updated", etc) and had no problems staying connected when i tried
it on my server (which has Access 2000) but unfortunately my client
isn't ready to upgrade their Access version.
Oddly though -- reports will work in Access 97 using the reserved field
name, it's just the forms and opening the table directly which caused
the ODBC to drop.
Thanks again!
Vicki
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!

ODBC Memory Leak

We are using ODBC connection pooling with SQL Server 2000 v5 on Win 2000 v5
sp4.

Each time we get a connection, SQLConnect, we see the memory usage go
up, about 52K. When we return the connection to the pool,
SQLDisconnect, and after the time that the connection remains in pool
expires we see the memory usage drop by about 28K.

Our basic steps for a select are:
SQLAllocHandle(SQL_HANDLE_DBC, hGblEnv, &hdbc);
SQLSetConnectAttr(hdbc, SQL_ATTR_LOGIN_TIMEOUT,
(SQLPOINTER)lLoginTimeOut, 0);
SQLSetConnectAttr(hdbc, SQL_ATTR_ACCESS_MODE,
(SQLPOINTER)SQL_MODE_READ_ONLY, SQL_IS_POINTER);
SQLConnect(hdbc,(SQLCHAR *)szDatabase, SQL_NTS,
(SQLCHAR *)szUserId, SQL_NTS,
(SQLCHAR *)szPassword, SQL_NTS);
SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt);
// Build the select statement
SQLExecDirect(hstmt, (SQLCHAR * )pszSQLStmt, strlen(pszSQLStmt));
SQLFetch(hstmt);
SQLFreeHandle (SQL_HANDLE_STMT, hstmt);
SQLDisconnect(hdbc);

Same memory leak occurs in DB2, but that's another forum.[posted and mailed, please reply in news]

M. Oakley (moakley@.acrosoft.com) writes:
> We are using ODBC connection pooling with SQL Server 2000 v5 on Win 2000
> v5 sp4.
> Each time we get a connection, SQLConnect, we see the memory usage go
> up, about 52K. When we return the connection to the pool,
> SQLDisconnect, and after the time that the connection remains in pool
> expires we see the memory usage drop by about 28K.
> Our basic steps for a select are:
> SQLAllocHandle(SQL_HANDLE_DBC, hGblEnv, &hdbc);
> SQLSetConnectAttr(hdbc, SQL_ATTR_LOGIN_TIMEOUT,
> (SQLPOINTER)lLoginTimeOut, 0);
> SQLSetConnectAttr(hdbc, SQL_ATTR_ACCESS_MODE,
> (SQLPOINTER)SQL_MODE_READ_ONLY, SQL_IS_POINTER);
> SQLConnect(hdbc,(SQLCHAR *)szDatabase, SQL_NTS,
> (SQLCHAR *)szUserId, SQL_NTS,
> (SQLCHAR *)szPassword, SQL_NTS);
> SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt);
> // Build the select statement
> SQLExecDirect(hstmt, (SQLCHAR * )pszSQLStmt, strlen(pszSQLStmt));
> SQLFetch(hstmt);
> SQLFreeHandle (SQL_HANDLE_STMT, hstmt);
> SQLDisconnect(hdbc);

There is a known issue with a memory leak in ODBC, described in
http://support.microsoft.com/?id=814410. This fix is included in SP3a,
but *not* in SP3, so you might want to investigate if this could be
the same.

However, I'm not completely sure that this is the same leak. I did get
a repro for the original leak, which lead to the fix in 814410, but not
programming ODBC much myself, I don't remember the details.

In any case, in case SP3a does not resolve the problem, could you compose
a complete repro that demonstrates the problem? That is a program that
I can compile and run? In such case, I should be able to bring it up
with Microsoft.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp