[AccessD] From a reader

Jim Lawrence accessd at shaw.ca
Wed Feb 9 12:12:12 CST 2011


Hi Shamil:

That looks like it could be a good product...I will have to investigate.

I do not do 'bound' forms and have not done any serious work, except when
supporting existing client applications, for going on 15 years. I am even
getting away from desktop apps and moving everything to web/browser based.
It's not a perfect solution but with a careful effort to produce a FE, very
heavy with JavaScript (JQuery) coding, a nice MS SQL BE, ASP.Net to do the
heavy lifting/roughing in the app (ASP.Net uses lots of JQuery code) and
then using managed and mostly hand-written AJAX connections...it seems to be
the best of all worlds.

I will definitely check out this Razor IDE.

Question: Has anyone used the MS product "Microsoft SQL Server Migration
Assistant 2005 for Access" to migrate an existing MDB to a MS SQL BE. What
type of preparation is necessary...any gottchas? Currently, I am moving two
MS Access apps to a MS SQL BE and want to expedite the process of moving the
data and queries. 
 
Jim



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil
Salakhetdinov
Sent: Wednesday, February 09, 2011 3:24 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] From a reader

Hi Jim --

MS does realize the issues "bound" to classical ASP.NET view engine - they
seems to have a solution:

Introducing "Razor" - a new view engine for ASP.NET 
http://weblogs.asp.net/scottgu/archive/2010/07/02/introducing-razor.aspx

It "works with any Text Editor: Razor doesn't require a specific tool and
enables you to be productive in any plain old text editor (notepad works
great)." :)

Well, but this "Razor" view engine seems to be bound to ASP.NET MVC? 

No, wait....

"Razor" view engine and DNN - they say it will be part of DNN 5.6.2 
http://www.dotnetnuke.com/Resources/Blogs/tabid/825/BlogID/15/Default.aspx

So

- ASP.NET
- "Razor" View Engine
- jQuery (it's supported by MS)
 =====================
Totals as a very advanced yet lightweight, fluid (flexible) Web development
platform resulting in clean HTML "by definition"? (I'm kidding about the
latter of course - one have to be very skilled in HTML and CSS to produce
clean HTML IMO).

And "Razor(CSHTML)" seems to be so much classical ASP like?

Thank you.

--
Shamil
 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
Sent: 9 ??????? 2011 ?. 10:18
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] From a reader

I think that ASP.Net is a great program but if you just let the system
create the forms for you, there will be so much traffic going on behind the
scene that a big commercial application would have to have a server farm
just to run it. By default the program wants to create some kind of bound
BE... total insanity as far I can see. (duck and cover) ;-)

What has to be done after the FE is boiler-plated together, is you have to
go in and remove hundreds of lines of extra code and hand code the data
connection... I know just how you feel. I have written very few applications
compared to the dozens I have had to come in and cleaned up. When the app is
completed it just snaps in comparison...and this is not rocket science...if
I can do it anyone can.

I think if any mid-range commercial application (20K hits per hour) needs
more that 2 servers to manage the operations BE; this is not counting data
storage, backup, fail-over, security or mail boxes but the real BE manager,
there is a problem with how the app was written. I have seen so many systems
where the techs just keep throwing more hardware at a blotted web
application when just cleaning up the code, would solve so many problems.

One day there may be a web building program that can build super tight code
but not today.

Jim  

 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka
Sent: Tuesday, February 08, 2011 4:21 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] From a reader

Hmmmm, actually, I'd be leery of a 'commercial site' using strictly notepad.
What about data?  Now if you gave them a blank .mdb, or access to a blank
SQL Database, and they created the entire data structure using T-SQL, ok,
I'd be impressed! LOL 

What is the most striking issue, in my book, is just understanding the
concepts of what your 'tools' are really doing in the back ground.
ASP.Net is pretty slick, but boy, if you don't really understand what it is
doing in the background, you are going to create one heck of a mess if you
aren't careful.

I just went through the wringer with a side project.  It's a rebuild of a
web form I built about 6 or 7 years ago.  The original form was built using
classic ASP, and VB 6 (for .dll's that did the business logic with the
database).  Way back then, I wasn't very good with javascript, so I was kind
of limited on what I was doing from the client scripting side.
They wanted several changes to that form, so we rebuilt it in .Net.
There's a very long story as to what put me through the most hell, but one
of the things that just boggled my mind was a 'custom' application they used
on their end.  They called it Passport.  Basically, it was a custom 'user
login' platform.  In an NT environment, with multiple forests/domains, an
'intranet' in such an environment can't truly utilize Active Directory
accounts.  Not without some serious workarounds.  So they built a 'system'
to allow users to 'log in' to their Intranet, that controlled what
applications various users could use.

Now, technically, all my system needed to know was the username of the
person currently 'logged in'.  That allowed me to filter certain information
for just that user.  That's it.  The rest of my application was strictly its
own system, with its own database, etc.  I had my project setup so that
there were only 3 places where I needed to 'inject' this custom systems
'logged in user', which I was using a querystring value for
development/placeholder purposes.  Instead of just saying, ok, use this
'code', what I ended up having to do, is setup a complete server (virtual)
with SQL Server, and VS 2010, so they could 'install' their system, because
they wanted me to send them a 'complete'
project.  The reality was, I had to take my project, and make it a 'sub'
project to theirs.  What a pain.  And what OVERKILL when it comes to that
system.  Lord have mercy, the complexity they threw into this thing......
it was the equivalent of using Airforce 1 as a golf cart.....

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
Sent: Tuesday, February 08, 2011 2:45 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] From a reader

No one should be able to build a web site with any tool until they can prove
they can build a commercial site with note-pad. ;-)

Jim



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka
Sent: Tuesday, February 08, 2011 11:30 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] From a reader

The funny thing is, the reason Access gets such a bad name is that it can be
used by amateurs, and when that happens, you get clunky.

A professional Access developer understands what an .mdb is.  They
understand the inner-workings enough to optimize performance. 

This is the same reason so many 'clunky' web applications have been made.

How many Access pro's could tell you EXACTLY what Jet is doing when you are
running 'SELECT * FROM tblSomething WHERE ID=1' against a table in a backend
.mdb?  Probably very few.  How many could give you a conceptual statement as
to what is happening, like 'Jet is reading the index values from the b/e
.mdb, and then using that information to determine where to start reading
the table data'?  Probably most.  Yet how many 'amateurs'
have even a conceptual understanding?  They don't need to, Access just does
things for them.

Same problem with the web.  There are a WIDE variety of tools available,
that let someone with little to no understanding of a
website/webserver/browser system throw a 'fully functioning' (<--- term used
very loosely) 'website' (<---also used very loosely) up into production.  It
has been this way for a while.  

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark Simms
Sent: Thursday, February 03, 2011 8:30 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] From a reader

I just LOVE that word "Clunky" to describe a web app !!

When everyone says how great the web is, I just point out all of the
"clunky" webapps I have to tolerate....from my bank, to my insurance
company, and on and on it goes. Then I get to a client site and have to
tolerate all of THEIR clunky webapps. They are slow, they don't respond,
they forget to validate, etc, etc., they don't integrate with windows, they
don't cut-and-paste properly, and the list just goes on forever.

I'm going for a long, long winternight's sleep. Someone wake me up when all
clunky web apps have been upgraded to Web 2.0 standards.


> make it 'look' like an access combobox, and act like it, but what's 
> happening in the background is clunky.  First, .Net is creating 
> javascript on the client side that is reacting to the 'OnClick' of the 
> combobox (or index changed event), then it's sending all the current


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list