My client has an Access application running on Terminal Server. Right
now they have 40 users, they're anticipating an additional 10-20 users
in the next couple years, and there are additional features they want
to build on to the system. The Access application has been developed
over the last 10 months. Tens of thousands of dollars have been spent
on development and on the Terminal Server itself.

They are now thinking that they want to migrate the back-end to SQL
Server and develop a web based front-end using ASP and/or .NET.

I'm wondering whether they would be making better use of their
investment in Access and TS by moving to a SQL Server back-end but
retaining Access as the front-end. But I've never tried this... would
TS work just as well (or better?) with a SQL Server back-end and an
Access front-end as it does with Access as both front and back?

Their users have some complaints about the clunkyness of TS... it
takes time to log on, it's hard to move files and copy and paste back
and forth from TS to client device, etc. But I wonder if these things
are a reasonable trade-off for the flexibility Access provides --
isn't it easier to customize on an on-going basis than with .NET? --
especially given the investment they've already made.

Any thoughts?

evenlater <evancater (AT) gmail (DOT) com> wrote in news:08624fbd-3905-4cb0-80a2-
8a56a1f49220 (AT) b38g2000prf (DOT) googlegroups.com:

ADP! No clunkiness. No file moving problems. Just screams of frustration
from the doomed, those who have modelled their development application on
Detroit Iron - Ugly, Inefficient and LAI. Probably most of your mdb stuff
works with very minor modification. An Access Form is an Access Form
whether it lives in an MDB or an ADP.

ASP is great too but it's expensive to develop in ASP,cuz you gotta do
EVERYTHING yourself. To have the program be really robust and powerful a
very competent scripter-coder-programmer is needed. There are a few of
those in the Access world, but they're pretty rare. Most Access guys are
pushin out 1997 stuff over and over and convincing newbies how clevah they
ah.

Asp.Net is the wave of the future unless that future is now which makes it
the wave of the present. Everybody seems to love it. I don't! It does too
much for me. And sometimes it doesn't let me do what I want without a
humoungous struggle. But that's just me. Maybe I'll change. (How I Learned
to Stop Worrying and Love the Bomb)

Rick Brandt posted here about Java and JDBC and Tom-something. I'm really
jealous. I want this. I can taste it and I'm droolin over it.
No, Phil, I ain't too old.
(But I may be too busy!)

--
lyle fairfield

On Mar 4, 5:36*pm, lyle fairfield <lylef... (AT) yah00 (DOT) ca> wrote:
You can hand code asp.net the same way you now hand code
classic asp. It's just programming. You do not have to use the
fancy pants controls and ajax enabled dodads if you don't want
to. Just use ado.net for data access and code the rest yourself.

I'm guessing all the html, css and javascript you code will be
leaner and meaner. It'll just take you longer.

rkc <rkc (AT) rkcny (DOT) com> wrote in
news:ddbe8af0-fe57-4ddb-9158-89ec8283c464 (AT) l22g2000vba (DOT) googlegroups.com:

I'd be grateful were you to post some sample code or a link to some
sample code.

--
lyle fairfield

So it seems we're going ADO.Net (pending the server actually being
enabled for ADP.Net, 99% likely). Your message was enough to push me
to that decision. Of course you realize, whose gonna be sworn at when
there are problems!

EH?

On Mar 4, 11:35*pm, rkc <r... (AT) rkcny (DOT) com> wrote:

On Mar 5, 6:34*am, lyle fairfield <lylef... (AT) yah00 (DOT) ca> wrote:
Not sure why you would want to see code from me. I've been stealing
your stuff for years.

If you get past all the crap asp.net writes to an html page and think
about all you really need it's no different than classic asp.

They are both server side languages. The browser still uses html,
javascript and css. It still sends the form and querystring variables
package as a request to the server in the same way. You can
still write code to get the elements of the request by using
the Request.Querystring and Request,Form collections. You
can still do simple database access using ADO.Net.

That's really all there is to it. The rest is just Microsoft
obfuscating what's happening.

rkc <rkc (AT) rkcny (DOT) com> wrote in
news:764b178c-88af-47b4-b25b-beb58565f2bb (AT) m36g2000vbp (DOT) googlegroups.com:

Thanks.

I am definitely going to try to do it thwt way you describe.

BTW, you may be able to fool some people with "Not sure why you would
want to see code from me. I've been stealing your stuff for years." but
I'm right over there on the other side of the lake and can look in your
window (figuratively) and you ain't foolin me. There are only a few
people I would say, "I'd like to see your code" to and you're one of them
.... and I've lifted some stuff from you too ... the MSXML stuff comes to
mind.



--
lyle fairfield

But how would ADP solve the long distance access needs? They're using
Terminal Server so users around the country can use the application
remotely. We could publish ADP forms and reports to the web using data
access pages... but hasn't MicroSoft given up on DAPs? We'd have to
downgrade our ACCDB to MDB just to get started, yes? When we were
first developing this application everybody I talked to said don't
bother trying to work with Access on the web, if you want a web-based
app just use ASP.

On Mar 5, 12:17*pm, lyle fairfield <lylef... (AT) yah00 (DOT) ca> wrote:

ADPs connect to MS-SQL Server using ADO / OLEDB. MS-SQL Server can be
Internet or Network enabled.

We create a new ADP. We use the Datalink dialog popup to specify the
logon properties: the name of the server, the name of the db, the user
id and the password. This takes 30 seconds or so.

Then we go about developing or importing our forms, reports, code etc,
or, in your case, import them. The data are just like data in the
local db and for the user, might just as well be.

And that's it. Have I done this? Many times. Have I been paid for
them? Yes, except those designed for my own use. Have I had
complaints. No. Do I use it myself? Yes. All my company stuff is in
California with DiscountAsp.Net. I am near Toronto, 4200 kilometers
away. Is it safe? I think so. Two years ago an MVP announced it was
not. I told him the location of my Server and asked him to "break in".
I'm still waiting.

I have a shortcut on my desktop to an ADP. The ADP connects to the
server and db in California. It has a startup continous form showing a
file of about 2000 financial transactions.

I click on the shortcut. How long before Access opens, loads my ADP,
connects to the server almost 3000 miles away over the internet, opens
my db, gets the records,and displays the form of transactions?

Four (4) yes thats one, two,three, four seconds. It's not forty
seconds, it's not four minutes; it's FOUR SECONDS. Is this faster than
some 100% local things? Sometimes, yes.





On Mar 5, 2:18*pm, evenlater <evanca... (AT) gmail (DOT) com> wrote:

There is one other attribute of adps that is mostly forgotten. They're
tiny. The adp I used in the description above is 45 kb. Not MB, it's
kb.

A major adp that I've worked on over the last year is 797 kb. (yes
I've been challenged on that ... "you charged us >*** grand for
797kb!!!!!!!!!!!!!!!!!!!!" ... I then printed out all the SQL which is
not part of the 797 kb and they felt a little better). Zipped, it's
166 kb. Moving, installing, copying, backing up such small files is a
snap.

On Mar 5, 3:02*pm, lyle fairfield <lyle.fairfi... (AT) gmail (DOT) com> wrote: