Access to VB.NET Conversion

[pwh777]

We have a large MS Access system made up of many large MS Access
applications. They run against a SQL Server. We are going to do a
conversion of this systim into VB.NET. We have a number of issues to
resolve. But, probably the biggest is the use of "Temp Tables".

In our applications we wrote queries to speed up some of the
processing. In many of these queries we use local tables for which we
would load into a subset of the SQL Server data. We called these local
tables our "Temp Tables". We would them update the local table data
and then push the data back up to SQL Server.

What can we do to mimic this?

[Bob Alston]

pwh777 wrote:

We have a large MS Access system made up of many large MS Access
applications. They run against a SQL Server. We are going to do a
conversion of this systim into VB.NET. We have a number of issues to
resolve. But, probably the biggest is the use of "Temp Tables".

In our applications we wrote queries to speed up some of the
processing. In many of these queries we use local tables for which we
would load into a subset of the SQL Server data. We called these local
tables our "Temp Tables". We would them update the local table data
and then push the data back up to SQL Server.

What can we do to mimic this?

Just curious as to why?

And do you mean it will still be a desktop app, just using VB instead of
Access forms?

Bob

[Trevor Best]

pwh777 wrote:

We have a large MS Access system made up of many large MS Access
applications. They run against a SQL Server. We are going to do a
conversion of this systim into VB.NET. We have a number of issues to
resolve. But, probably the biggest is the use of "Temp Tables".

In our applications we wrote queries to speed up some of the
processing. In many of these queries we use local tables for which we
would load into a subset of the SQL Server data. We called these local
tables our "Temp Tables". We would them update the local table data
and then push the data back up to SQL Server.

What can we do to mimic this?

Rewrite that part as stored procedures, which can use their own temp
tables if neccessary.

--
This sig left intentionally blank

[pwh777]

The new apps that we will be creating will be published apps. The
users will sign into a Citrix environment which will load a menu
screen. From this menu screen they can select from the multiple apps
that we have.

Bob, are you asking why we want to mimic the temp table process? If
so, we want to because of time and performance. First, on
performance...initially many of the processes were written just using
code. By using temp tables, it sped up the processes quite a bit. We
believe the same will be true of VB.NET.

Another reason is that we will be on a time crunch. If we can mimic
running the queries that we already have all we would need to do is get
the SQL code out of the queries and into this new method (whatever it
is). It would take us a lot longer to have to rewrite doing what the
queries do using code.

Trevor, how would stored procedures resolve this? We are aware of a
few different solutions:
1. Generate SQL temp tables on the fly.
2. Have the temp tables already created in SQL Server. Each table
will have
a token for concurrency.
3. Use Access temp tables (this will probably not be an option).