 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / General 1 / February 2006SQL Server Express: Anybody Using It?
I skimmed the MS spiel at http://msdn.microsoft.com/sql/express, and noted the part about "all inside the Visual Studio 2005 environment". Do the older SQL server tools for security and stored procedure editing work too?  SignaturePeteCresswell I am using it.Access 2003 ADPs can do some editing of an SQL Express db design, but not everything; TTBOMR table design is not modifiable with Access 2003 ADPs; Stored Procedures are, but we are warned that they are not. But the various .Net technologies come with a very nice utility for editing tables, stored procedures etc in SQL Express; since it's a lot slicker than the Access utility, I don't miss the Access capability at all. I don't know about security. I have noticed zero difference, but then, I have't looked at this topic. Per Lyle Fairfield: > But the various .Net technologies come with a very nice >utility for editing tables, stored procedures etc in SQL Express; since >it's a lot slicker than the Access utility, I don't miss the Access >capability at all. So, if I install the .NET development environment on one of my boxes, I should be good to go.... BTW: Can SQL Server Express be run on one machine and used by apps on another machine? i.e. Could I offer it as a functional alternative solution to .MDB based apps where 5-10 users share the same back end over a LAN connection? If so, it would seem like the better path to take instead of using a .MDB as long as the administrative part isn't too daunting for a regular LAN-type person. SignaturePeteCresswell I haven't done this (used SQL Express on Machine A from Machine B on a LAN (hmmmmmm .... maybe I have, but I'm away right now and can't check). Be advised that connecting to SQL Express after it is installed can be challenging. MS didn't choose to make it useable out-of-the-box, so to speak. Fortunately it's so challenging that there are multiple posts to newsgroups about the problems that arise and solutions for them. >I haven't done this (used SQL Express on Machine A from Machine B on a > LAN (hmmmmmm .... maybe I have, but I'm away right now and can't [quoted text clipped - 4 lines] > speak. Fortunately it's so challenging that there are multiple posts to > newsgroups about the problems that arise and solutions for them. I did this a few months ago just to have a look around. The bit I remember getting caught with was the deafult WinXP SP2 firewall which stopped me connecting to the database. Although I spent over an hour looking at other things before I worked that one out. Doh! Per Anthony England: >I did this a few months ago just to have a look around. The bit I remember >getting caught with was the deafult WinXP SP2 firewall which stopped me >connecting to the database. Although I spent over an hour looking at other >things before I worked that one out. Doh! I've been nailed by my firewall (another brand...) a number to times just using SQL Server Developer's Version/MSDE. Can't remember how many times... but eventually it soaked in and I update the firewall's list by habit now. SignaturePeteCresswell > Per Anthony England: >>I did this a few months ago just to have a look around. The bit I [quoted text clipped - 8 lines] > Can't remember how many times... but eventually it soaked in and I > update the firewall's list by habit now. It would be better to change your SQL Server to use a nonstandard port and unblock *that* port. Then, only exploits that scan all ports would be able to attempt a connection to it. If you use default ports, it's just an open invitation to nefarious interests. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > Be advised that connecting to SQL Express after it is installed can be > challenging. MS didn't choose to make it useable out-of-the-box, so to > speak. Works fine for me: ------------------------------ Dim cnxn As ADODB.Connection Set cnxn = New ADODB.Connection cnxn.ConnectionTimeout = 1 cnxn.ConnectionString = "Provider=sqloledb;" & _ "Data Source=.\SQLEXPRESS;" & _ "Initial Catalog=mdfFileName;" & _ "Integrated Security=SSPI" cnxn.Open ------------------------------- I would also note that SQL Server Express without Visual Web Developer Express is like Jet without Access. SignatureDarryl Kerkeslager Then SQL Server Express with Visual Web Developer Express is like Jet with Access? > Then > SQL Server Express with Visual Web Developer > Express is like Jet with Access? Um, no, not exactly .. bit of a logic error, there. However, the following three (free) MS products, combined, offer more than Access/Jet: Visual Web Developer Express 2005 SQL Server 2005 Express Visual Basic 2005 Express - Development for a sever database and desktop database can be done identically - no need to be concerned about having to upgrade/replace the desktop app at some point - The VB.Net language can be used for console, web, and database apps, a slight improvement over VBScript, VBA, and VB (although VB.Net does not do Office apps). - Web development is integral, without ADP or ASP. - performance of SQL Server vs. Jet - both are so fast on a single desktop, that it doesn't even matter. It would take someone who is an expert in both Access/Jet/VBA and ADO.Net/SQL Server/VB.Net to truly compare the RAD power of both - but I would say the combination of these three products (all currently free) have so many strengths, that Access now has serious competition for the first time for developers who want to work independently and develop great standalone database products. The last adverb for that sentence would be "quickly" - but I don't know about that, and I'm not sure there are enough true experts in both to know. Disclaimer: All of this is IMHO, is not intended to ignite flames, and is based on as yet limited fiddling with the above three tools. SignatureDarryl Kerkeslager > However, the following three (free) MS products, combined, offer more than > Access/Jet: > > Visual Web Developer Express 2005 > SQL Server 2005 Express > Visual Basic 2005 Express I've done some of this; it's as fast or faster to develop than Access; it's as powerful or more powerful than Access; it's far easier to deploy than Access. Access is over, done, finished, dead! Per Lyle Fairfield: >I've done some of this; it's as fast or faster to develop than Access; >it's as powerful or more powerful than Access; it's far easier to >deploy than Access. Can 10 different PC's concurrently connect their MS Access front ends to a single instance of Access Express running on some other PC? SignaturePeteCresswell Access Express? Per Lyle Fairfield: Oops.... SQL Server Express.. SignaturePeteCresswell My Installed SQL SERVER Express returns for SELECT @@MAX_CONNECTIONS 32767 The SDK says that @@MAX_CONNECTIONS Returns the maximum number of simultaneous user connections allowed on an instance of SQL Server. The number returned is not necessarily the number currently configured I believe that this number can be modified. > However, the following three (free) MS products, combined, offer > more than Access/Jet: > > Visual Web Developer Express 2005 > SQL Server 2005 Express > Visual Basic 2005 Express And is the result hosted in a web browser? If so, it just isn't comparable. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > And is the result hosted in a web browser? Could be; doesn't have to be. I don't have all the answers - I'm just looking into a lot of this and trying it out, myself - but it does seem pretty promising. You can write executables - no "runtime version" required. I see no reason in the documentation why you shouldn't be able to use it over a LAN (and since the documentation mentions concurrent users, I guess that would logically follow). I have 80 users connected to my Access db now - maybe 40 concurrent - could I also do 40 concurrent users with SQL Server Express with the 1 GB RAM limit - I have no idea. I'm certainly not worried about the 4GB data file limit. Can I develop software as quickly with .Net as with Access? Don't know that either - but I will say that I have coded a heck of a lot of VBA in Access, and Access isn't the magical RAD tool I once thought it was. So I'm willing to give something else a shot. SignatureDarryl Kerkeslager Per Darryl Kerkeslager: >Can I develop software as quickly with .Net as with Access? Don't know that >either - but I will say that I have coded a heck of a lot of VBA in Access, >and Access isn't the magical RAD tool I once thought it was. So I'm willing >to give something else a shot. My one experience doing the same, identical app in MS Access and VB6 resulted in a 1:3 ratio of man hours. I did the Access version first, so probably got something of a free ride on the VB6 version design-wise. Others have opined as high as 1:5. At least one guy has claimed to me that he can develop the same app either way in the same number of man hours. I've got trouble with that one - if only because of little things like creating/aligning labels for text boxes and the extra code needed for auto-scrolling combo box drop downs. Of the two apps that I wrote only to have somebody's IT department rewrite them as net-centric, one was delivered by me for about 70k but cost over 3 mil to have reproduced as net-centric. The other was delivered by me for something under 250k over five years and rewritten in 100% .NET against an Oracle DB. Last time I checked, it was supposed to be almost ready for production and they'd spent over 23 mil on it. With that one, there was an increase in functionality - but more like 30-40 percent than 1,000 percent. SignaturePeteCresswell > Can I develop software as quickly with .Net as with Access? Don't know > that either - but I will say that I have coded a heck of a lot of VBA in > Access, and Access isn't the magical RAD tool I once thought it was. So > I'm willing to give something else a shot. The new vb.net does a really incredible job of handling the "connection" to the database. This something that ms-access has been better at then just about everything else in the marketplace for years. So, data binding in the new .net is really nice. However, having to install a server based system. (that has to startup/shutdown) when you application runs, and the lack of a integrated reporting that ms-access has still makes ms-access a rad tool of choice. Further, things like sub-forms, and even more incredible is continues forms in ms-access...such as noted here: http://www.members.shaw.ca/AlbertKallal/Articles/Grid.htm Further, nothing as mentioned is stopping one from using the sql express as the data engine. However, the last 3 copies (that is a LONG time) of office has shipped with a free edition of sql server for use with ms-access. So, the advent of sql express does not change this formula in a huge way (there is no throttle on the new express..so, sure..it is better then the free MSDE). It still only takes one line of code to open a form..and sent it to a particular invoice number in ms-access. Those other .net systems while good...still are NOT in the genre of ms-access in terms of rad development. And, they still don't have a integrated report writer that is close to ms-access one.... FoxPro, FileMaker, Ms-access etc. all exist because a general purpose programming system like vb.net can never really equal the abilities of system DESIGNED for database data entry. I would not use ms-access to write a pac man game...but vb.net would be good choice. And, it don't make sense to write a CAD system in vb.net when you have AutoCAD. The right tool for the right task is critical here. As new technology rolls out, it is integrated into ms-access. When VB got class objects...then ms-access got it. When ADO came out...ms-access got ADO. When XML became all the rage....the last two versions of ms-access has had xml features added. We have add-is for source code control. And, we even now have a SOAP ad-in to consume web services. If your application requirements go beyond a typical data entry application (CRUD = create, read, update,delete), then ms-access might not be the best choice. However, for most small business applications....even if you use sql server...ms-access is still the best choice IMHO.... The only real reason why the new vb express + sql express can challenge ms-access is because it is free..and ms-access is actually now a premium priced product from ms.... SignatureAlbert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal@msn.com http://www.members.shaw.ca/AlbertKallal > However, having to install a server based system. (that has to > startup/shutdown) when you application runs, and the lack of a integrated > reporting that ms-access has still makes ms-access a rad tool of choice. > Further, things like sub-forms, and even more incredible is continues > forms > in ms-access...such as noted here: Not sure what the problem is with the server-based system ... ? I understand SQL Server Express is supposed to get the new SQL Reporting tools as well ... but since I don't know how easy they are to use, I don't know what to reply. I will agree, that the ease of use of Access Reports will be hard to beat. For me, though, I see a great benefit in doing Windows and web, PC and server, in one language (VB.Net), one data model (ADO.Net), and one database (SQL Server). Basically, I'm buying the Microsoft marketing hook-line-and-sinker. And, as an incidental note, there are a whole lot more jobs out there for people with the above areas of knowledge than there are for Access/Jet/DAO. This may not matter to those who have a secure living already carved out with Access, but I don't. SignatureDarryl Kerkeslager > For me, though, I see a great benefit in doing Windows and web, PC and > server, in one language (VB.Net), one data model (ADO.Net), and one > database (SQL Server). Basically, I'm buying the Microsoft marketing > hook-line-and-sinker. Well, actually, what they done is really incredible. Further, I been waiting patiently for TEN YEARS to give me a server product that lets me write in a decent language..and have the server run and consume that code. The fact that I don't have to try and write really crap code in t-sql, and can now use vb(net) to write my code for the server side is really a killer concept. Why use a lousily server side language....it never made sense. My time on systems like D3 and Universe taught me how nice it is to have a really nice programming language on the server side (these are mainframe systems, .but in their form to today, the database programming language on these systems is now simply the server side coding language). So, sure..there is some marketing here..but golly, that .net platform is really nice..and the same system can be used to write code for sql server, or your pda , or web services or next week for your desktop!! This is much like the grand unified theory that Einstein was looking for......... While the whole .net genre was overhyped...the integration of all technologies from sql server to the web to desktop to pda is now a reality. People have not yet grasped how important this crossover system is called .net is. SignatureAlbert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal@msn.com http://www.members.shaw.ca/AlbertKallal Per Darryl Kerkeslager: >For me, though, I see a great benefit in doing Windows and web, PC and >server, in one language (VB.Net), one data model (ADO.Net), and one database >(SQL Server). Basically, I'm buying the Microsoft marketing >hook-line-and-sinker. I've been trying to - but when I ask myself what I *really* do, the answer comes out something like "I deliver usable applications in a much shorter timeframe than IT can and for substantially fewer dollars.". Given that, I'd need to develop some kind of CRUD skeleton in .NET that I can clone/customize in some reasonable approximation of the time it takes to turn out the same thing via MS Access. >And, as an incidental note, there are a whole lot more jobs out there for >people with the above areas of knowledge than there are for Access/Jet/DAO. >This may not matter to those who have a secure living already carved out >with Access, but I don't. I'd agree with that, but keep my eye on the ripples from Bangalore. SignaturePeteCresswell >> However, having to install a server based system. (that has to >> startup/shutdown) when you application runs, and the lack of a [quoted text clipped - 4 lines] > > Not sure what the problem is with the server-based system ... ? Well, you have two choices: 1. start up the SQL Server service at boot, OR 2. start it up on demand and then shut it down when finished. For security and performance reasons, I'd certainly prefer the latter. Of course, I'm assuming here a single-user application, and in that situation I just can't see the utility of a server db engine running locally, except if your app must support both single users and shared users. [] > For me, though, I see a great benefit in doing Windows and web, PC > and server, in one language (VB.Net), one data model (ADO.Net), > and one database (SQL Server). Basically, I'm buying the > Microsoft marketing hook-line-and-sinker. Well, if you're *doing* browser-based, web-hosted apps, that makes sense. For those of us who only do Access apps, it looks like the tail wagging the dog -- implementation of features that do us absolutely no good. This was the case with Access 2000's implementation of all the server-friendly features, things that I didn't need then and don't need now. Frankly, I would have expected to be porting my apps to SQL Server back ends by now, but Jet has held up just fine in terms of performance and reliability. The cost of converting has been ridiculously out of scale with the benefit that would have come from it, and no one is more surprised than me that Access/Jet continues to hold up under loads that I would have considered shading into the realm of problematic. > And, as an incidental note, there are a whole lot more jobs out > there for people with the above areas of knowledge than there are > for Access/Jet/DAO. . . . I think that's an artifact of buzzword-driven HR departments. Access is the hidden development platform that the pros turn up their noses at. Because of that, job descriptions seldom include Access as one of the required skills. > This may not matter to those who have a secure living already > carved out with Access, but I don't. I think the potential market for Access apps continues to grow. There is no shortage of small businesses who need customized database applications, and there never will be. For those businesses, there is no purpose served by "webifying" those apps, especially now with Windows Terminal Server deployment being so incredibly easy (and built into Win2K3 Server). Without wide WTS availability, the pressure to go browser-based would be pretty severe, but WTS has made it possible to make plain old Access apps available to anyohe anywhere, with the most minimal client-side software installation (and with Windows PCs that are 3+ years old or younger, no client software at all). SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ >> And is the result hosted in a web browser? > > Could be; doesn't have to be. How else would the application be run? An executable? > I don't have all the answers - I'm just looking into a lot of > this and > trying it out, myself - but it does seem pretty promising. For browser-based applications, certainly. As a replacement for Access, it's hopeless, seems to me -- it can't come close. > You can write executables - no "runtime version" required. > [quoted text clipped - 12 lines] > lot of VBA in Access, and Access isn't the magical RAD tool I once > thought it was. So I'm willing to give something else a shot. I think that people who never use the RAD tools in Access should probably be looking at something else. I also think that there are an awful lot of unnecessary unbound forms out there in Access apps, and this is one of the reasons so many people end up with so much code -- they aren't using Access for what it's good for. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > How else would the application be run? An executable? Yes. > For browser-based applications, certainly. > > As a replacement for Access, it's hopeless, seems to me -- it can't > come close. Again, I'm still learning about the software capabilities, so at the risk of being misinformed ... These data controls seem very similar in capability to Access (again, keep in mind that I'm reading the docs, not actually using these controls yet): http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/vs2005pro/smart_client /DataCentricOverview.htm > I think that people who never use the RAD tools in Access should > probably be looking at something else. I also think that there are > an awful lot of unnecessary unbound forms out there in Access apps, > and this is one of the reasons so many people end up with so much > code -- they aren't using Access for what it's good for. All my forms are bound ... there's still a lot of code ... -- Darryl Kerkeslager > > How else would the application be run? An executable? > [quoted text clipped - 11 lines] > keep in mind that I'm reading the docs, not actually using these > controls yet): Ah, there you go. Actually try them and then report back. I spent an exploratory few weeks with visual studio and dot-net and the amount of work required just to get a record displayed on a form was staggering. SignatureI don't check the Email account attached to this message. Send instead to... RBrandt at Hunter dot com With Visual Web Developer 2005 Express Edition (free) I dragged an MS-SQL View onto a aspx page and voila ... it's there as a datagrid, like a continuous form, paged, sortable ...each row select-able, editable, delete-able ... time required ... about 5 seconds ... alternate line formatting? ... another few seconds. I'm learning ... and fooled around for the better part of a day with styles, appearance, authentication and insert. When I got those passable, I created a similar page for another view ... time about 2 minutes; I simply changed my SQL string and my field names and headers headers and my parameters. Tomorrow (maybe!) I'm going to experiment (or i'm going to watch the Canadian Curling Teams at the Olympics) with ListBoxes ... Totals ... conditional formats like red for negatives ... other gnarly things ... I expect I'll be baffled by some ... but once I solve them I'll be ... well I think I MAY be ... much faster than developing in Access ... and I've been developing in Access for a long, long time ... I think 1991 but I'm not sure Access was around in 1991. And when I want someone in Slovenia to be able to work with this ... I send them a site address, a username and a password ... and THAT's it ... Yeah ... I know ... what about reports ... probably that's a March or April investigation. Maybe reports will be the fatal flaw. But right now I think Access is dead. When Office renewal time comes I'll go to Corel ... Quattro Pro is fabulous ... I'll do my db stuff on the web. Access is, as Tiger Williams would say, "Done like Dinner!". > But right now I think Access is dead. I disagree with that. But it is clear that most of the changes to Access that the 'Softies have blogged are in end-user functionality. > I'll do my db stuff on the web. You may have found good tools for web database stuff, but the web isn't an appropriate venue for many kinds of application -- if they don't "break" the capabilities we have now, but do enhance the user experience, Access'll be around, and useful, for a long time. > Access is, as Tiger Williams would say, "Done > like Dinner!". We shall see. If so, it's been a good ride, and a longer one that you get with most software. Larry Linson Microsoft Access MVP > > But right now I think Access is dead. > > I disagree with that. But it is clear that most of the changes to > Access that the 'Softies have blogged are in end-user > functionality. But is that not simply a result of the order in which they are going through the functionality, starting with the new aspects of the user interface (which will be, by definition, the end-user part of the equation), and leading up to the developer features? >> I'll do my db stuff on the web. > [quoted text clipped - 3 lines] > the user experience, Access'll be around, and useful, for a long > time. My bet is that these web pages Lyle is creating use proprietary, IE-only coding that won't run in any other browser, which makes it completely unacceptable as far as I'm concerned, since IE is not an acceptable browser for use by anyone (and IE7 isn't going to change that -- the problems are too fundamental to the design of IE and Windows). > > Access is, as Tiger Williams would say, "Done > > like Dinner!". > > We shall see. If so, it's been a good ride, and a longer one that > you get with most software. Many Access developers outgrow Access as their development platform and move on. So, "done for Lyle" does not at all mean that it's no longer a viable product serving a large and vital market. So far as I can see, Microsoft seems to be investing quite a bit of effort into making Access better, which suggests to me that they aren't about to abandon it. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > My bet is that these web pages Lyle is creating use proprietary, > IE-only coding that won't run in any other browser, which makes it > completely unacceptable as far as I'm concerned, since IE is not an > acceptable browser for use by anyone (and IE7 isn't going to change > that -- the problems are too fundamental to the design of IE and > Windows). No, I don't use IE except for things like Winodws Update. I am testing my pages in Firefox, K-Meleon and Netscape. > My bet is that these web pages Lyle is creating use proprietary, > IE-only coding that won't run in any other browser, which makes it [quoted text clipped - 6 lines] > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/ David, Visual Studio 2005 produces compliant HTML by default, at least in my experience. Obviously the developer needs to deal with different browsers, and the lack of standards compliance in IE is a definite issue. But the built in controls provided by ASP.NET produce compliant HTML, using VS 2005 and the .NET framework 2.0 (and the IDE flags bad markup). I'm not commenting on the time to develop required by these platforms at all, just adressing that one issue. SignatureEd >> My bet is that these web pages Lyle is creating use proprietary, >> IE-only coding that won't run in any other browser, which makes [quoted text clipped - 5 lines] > Visual Studio 2005 produces compliant HTML by default, at least in > my experience. . . . But it's styled by CSS, no? And IE6 is the least CSS-compliant current browser out there. Secondly, there's JavaScript (or, if VS is really stupidly designed, JScript or VBScript), which is not cross-compatible between IE and other browsers if the IE-only document model is used. If it were just pure HTML, then it wouldn't be very useful at all, so I can only presume that people are getting excited about VS producing something a lot more elaborate than plain old garden-variety HTML, and that means client-side scripting with CSS/CSS2. > . . . Obviously the developer needs to deal with different > browsers, and the lack of standards compliance in IE is a definite > issue. But the built in controls provided by ASP.NET produce > compliant HTML, using VS 2005 and the .NET framework 2.0 (and the > IDE flags bad markup). Eh? How does the client side of an application delivered in a browser depend on the .NET framework? That's even worse if it does. As to the "built in controls" what does that mean? Does something have to be downloaded, or are these predefined classes that your code can use to get extended functionality from the standard widgets plus DHTML? > I'm not commenting on the time to develop required by these > platforms at all, just adressing that one issue. You haven't really said anything that convinces me that VS is producing good cross-browser code. If it renders differently in IE than in FireFox, then it's not properly compliant. Based on my experience with Outlook Web Access in IE vs. other browsers, I'd be very surprised if MS would sacrifice additional functionality just so that the code was not IE-specific. It would go against the whole organization of all MS product lines, which is to decommoditize standards and force you to build into your apps dependencies on MS technologies and products (unless you sacrifice functionality). SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ David It's not dependent on IE; It doesn't run in IE, or on the client at all for that matter; There is no browser code (except the Client Script one might find in any HTML page, but this has nothing to do with the ASP.Net application); It's identical in form and substance on five browsers that I have obswerved; It can be styled by CSS but it also has its own visual properties, so this is optional; Nothing has to be downloaded; It's great, fast, simple and powerful. > >> My bet is that these web pages Lyle is creating use proprietary, > >> IE-only coding that won't run in any other browser, which makes [quoted text clipped - 18 lines] > garden-variety HTML, and that means client-side scripting with > CSS/CSS2. It produces HTML and javascript. CSS is up to the developer/designer. It works across browsers just fine, although it is subject to the same browser incompatibilities as any other web development process is. > > . . . Obviously the developer needs to deal with different > > browsers, and the lack of standards compliance in IE is a definite [quoted text clipped - 9 lines] > code can use to get extended functionality from the standard widgets > plus DHTML? No downloads. I'm talking about built in server controls that are data aware. So at design time you can bind data sources to controls (which are very extensible), attach methods to button clicks and do other RAD-like development tasks. When the page is actually requested by the browser, standard HTML and Javascript is delivered to the browser. Nothing MS-only. It's not RAD like Access is RAD, but for a web developer it's a pretty big advance. > > I'm not commenting on the time to develop required by these > > platforms at all, just adressing that one issue. [quoted text clipped - 8 lines] > standards and force you to build into your apps dependencies on MS > technologies and products (unless you sacrifice functionality). Yeah, I've used OWA as well, so I know what you mean. But the fact that code renders differently in IE vs other browsers is not due to the development tool. I could write my code in Notepad, and it could still render differently in IE as opposed to Firefox. Older MS development tools attempted to bring some RAD properties to web development, but FrontPage (at least back in the day, I don't know what it does now) and Visual Interdev produced heavily IE specific code, not to mention lousy HTML. Visual Studio 2003 was a lot better; it didn't produce compliant markup by default, but it was somewhat better behaved with non IE browsers. VS 2005 is a big step forward, IMO, though. It really is pretty browser neutral. It produces compliant markup by default. I can drop server controls onto my page, wire up a data source, and get cross browser HTML just like that. I'm an old Access developer who gradually moved to web applications, and to be honest I can see a fair amount of Access 'philosophy' in ASP.NET. Along with a lot of other things, of course, I'm not saying it's merely an attempt to bring RAD practices to wweb development. But going from Access to classic ASP was a real shocker. When I started using ASP.NET, it was much closer to Access-style development. I don't mean to sell it. As I said, it's not RAD like Access is RAD, and if you're not doing web apps it's irrelevant anyway. But it's a good tool, IMO, and something that actually allows you to support clients who are using any platform or browser, not only Windows and IE. SignatureEd > It's not RAD like Access is RAD, but for a web developer it's a > pretty big advance. Well, sure. No one is disputing that. The question is whether it gets even close to Access's level of RAD. It doesn't, and the only reason it's a big success with web developers is that they haven't a clue what the standard is for RAD because they think Access is a toy. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Oh no, It's quite RAD. But I don't think there's anything to worry about; Access Developers should have no difficulty at all shifting over unless they never learned ADO in which case the ADO.Net model is likely to be a mystery. It's Sunday so maybe a little truth in posting is in order here: My opinions - findings - nothing in stone for sure: 1. Visual Web Developer 2005 Express (VWDE) is a great vehicle for me to write my ASP-ADO Net apps; 2. VWDE's web controls are fast and great for flat file type tables; 3. I have not yet found anyway to have my pull downs start with the selected value as the value of the field in my main table; 4. I have not yet found a way to set the selected day of the Calendar Web Control to the value of a Date field in my main table. Of course, it's quite possible that these "ways" exist and that I just haven't been able to find them. It's also possible that they exist only in the versions of Visual Web Developer 2005 that cost. In the meantime, I can't do with VWDE what I can do with the old ASP-ADO technologies, and certainly, it doesn't approach Access as a RAD platform. BTW, the Calendar control is, to my mind quite basic and disappointing. The aspx web pages can take a long time for initial load. And I was unable to use the Calendar Control without posting back to the server every time I chose a date, causing, of course, the screen of flash and be redrawn. I'll state once again that all these problems may be due just to my inexperience. > With Visual Web Developer 2005 Express Edition (free) I dragged an > MS-SQL View onto a aspx page and voila ... it's there as a datagrid, > like a continuous form, paged, sortable ...each row select-able, > editable, delete-able ... time required ... about 5 seconds ... > alternate line formatting? ... another few seconds. With any version of access I can link to a SQL Server view and just like that I've got a datagrid that I can page, scroll, sort, edit, each row selectable. Time required maybe 30 seconds. Do I have an application? Grids are cheap and easy. Almost no one would expose an Access datasheet to a user and call it an "application", but make a grid appear in a web browser and now it's a piece of magic. Now give your user CheckBoxes for Yes/No fields, drop downs that show one thing while storing another. Master/Detail interfaces or the equivalent functionality of an OptionGroup frame. If these can be accomplished in a few minutes time with VS/Dot-Net then I must admit that I simply could not see it. Perhaps Visual Web Developer is quite different from full-blown Visual Studio. > I'm learning ... and fooled around for the better part of a day with > styles, appearance, authentication and insert. I do the same thing in my Ajax development. What would take a few minutes in Access takes hours in a web environment and that doesn't even take into account trying to make sure that the page works and looks correct in anything besides Internet Explorer. > When I got those passable, I created a similar page for another view > ... time about 2 minutes; I simply changed my SQL string and my field [quoted text clipped - 7 lines] > and I've been developing in Access for a long, long time ... I think > 1991 but I'm not sure Access was around in 1991. You'll likely have a ball and learn a lot of new stuff (who doesn't like that?), but I doubt that you will ever approach the development speed that you could with Access. Our company is switching all new development from Access/Delphi/RPG to Web apps using Ajax methods. I find it incredibly interesting and haven't been this enthused about coming to work in ages. Will any of my users benefit from this change? I extremely doubt it. Stuff I used to give them in minutes now go into the queue and when I get to them it will likely take a day or two for the easy stuff and a week or two for the more complicated stuff. Now, if I were independent and my wages depended on getting the job done as quickly as possible so I can move onto the next one I most certainly would use Access unless there was something (technical or political) that forced me to do otherwise. SignatureI don't check the Email account attached to this message. Send instead to... RBrandt at Hunter dot com > Now give your user CheckBoxes for Yes/No fields, drop downs that show one > thing while storing another. Bit fields defaulted to Check Boxes. I did zip to achieve this functionality. I haven't got to Drop Downs yet but I was encouraged when I dragged a ListBox onto the page/grid and was able to enter the bound field and data source (my terms not those used by Visual Studio). I've done some DropDowns now; they're about the same as Access PullDowns; of course, they'll get easier as I become familiar with them. They let me filter my DataGrid easily and very quickly. >> With Visual Web Developer 2005 Express Edition (free) I dragged >> an MS-SQL View onto a aspx page and voila ... it's there as a [quoted text clipped - 10 lines] > datasheet to a user and call it an "application", but make a grid > appear in a web browser and now it's a piece of magic. Yes, grids are relatively trivial. I could knock out PHP code to do the same thing in about 2 minutes, myself, with no drag and drop. It wouldn't be beautiful, but it would display the contents of a data table in tabular form. > Now give your user CheckBoxes for Yes/No fields, drop downs that > show one thing while storing another. Master/Detail interfaces or > the equivalent functionality of an OptionGroup frame. If these > can be accomplished in a few minutes time with VS/Dot-Net then I > must admit that I simply could not see it. Perhaps Visual Web > Developer is quite different from full-blown Visual Studio. Well, it's possible now with AJAX to develop much richer client-side user interfaces for use in a browser. But those are created by extending the standard HTML form widgets with JavaScript extensions and event handlers. My bet is that if the tools Lyle is raving about are implementing these features, they are *not* doing it in a cross-browser compliant way. Look at the Exchange Server 2003 Outlook Web Access feature -- it uses AJAX techniques, but in a way that works completely differently on IE than in other browsers. The full-featured UI is available only with IE. Tying your app to such a poor browser is a big mistake, in my opinion, and you're also tying yourself (with ASP.NET) to Microsoft server products and Windows-based hosting, which is generally more expensive and less common than Apache/Linux-based hosting. >> I'm learning ... and fooled around for the better part of a day >> with styles, appearance, authentication and insert. [quoted text clipped - 3 lines] > doesn't even take into account trying to make sure that the page > works and looks correct in anything besides Internet Explorer. Anyone with any sense starts writing their HTML/CSS/AJAX for Firefox and then figures out what doesn't work right in IE and patches that (IE has tons of terribly CSS incompatibilities, which MS has failed to promise to fix in IE7). >> When I got those passable, I created a similar page for another >> view ... time about 2 minutes; I simply changed my SQL string and [quoted text clipped - 12 lines] > doesn't like that?), but I doubt that you will ever approach the > development speed that you could with Access. Because browser-based apps are stateless, they require more screens than Access does to accomplish the same tasks. And the widgets, even with AJAX, are never going to be as rich as those available even in Access 2. > Our company is switching all new development from > Access/Delphi/RPG to Web apps using Ajax methods. I find it [quoted text clipped - 4 lines] > two for the easy stuff and a week or two for the more complicated > stuff. One of the things that's happening, though, is that the people who do web development *do* find .NET to be very helpful, since it's far more productive than the old methods, because the development environment is so good (I hear). They are seeing large improvements in productivity. But they've never experienced Access-style RAD development, so they don't realize how incredibly far they are from true quick development of apps with a rich UI. > Now, if I were independent and my wages depended on getting the > job done as quickly as possible so I can move onto the next one I > most certainly would use Access unless there was something > (technical or political) that forced me to do otherwise. I don't understand why people think web-oriented development techniques can possibly replace the speed and richness of a desktop application's UI, with native OS widgets and bound data (rather than being stateless). And, as Larry said, many apps don't belong on the Web, so you're actually crippling their functionality and making them harder to use by converting them to be hosted in a web browser. As you say, this is a very user-hostile thing to do, and I don't understand why people think it's a good idea. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > Yeah ... I know ... what about reports ... probably that's a March > or April investigation. Maybe reports will be the fatal flaw. Do all these magically created web pages work in all the good web browsers (that is, anything but Internet Explorer)? Or are they built of IE-only code? And can the results be run on something other than ASP.NET, which is proprietary to Microsoft, and doesn't run on anything but Windows servers (which no one in their right mind should be choosing for production, Internet-facing websites)? Or does all this development with these super-duper tools tie you down to Microsoft products on the server side? I have not as yet had a client ask me to put their application on a web site (they often ask if they can access it via the web, by which they mean remotely, not actually in a web browser), and that can be easily implemented with Windows Terminal Server. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ I wonder what this means, "hosted in a web browser". HTAs and DAPs are hosted in Internet Explorer. That's clear. But as I see .NET (aspx) applications, everything is done on the server; they send html (perhaps xhtml) to the client's browser and they get data posted back, but nothing is "run" on the client, So far in my testing they have worked flawlessly on IE, NS, Firefox and K-Meleon. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.