Access Experts: General discussion thread for Access Zone (04-Sep-2011)
This thread is intended for general discussion among Experts participating in the Access zones.
Discussion topics can include (but are not limited to) Access and zone related issues, tips, tricks, news, events etc.
This thread is publically visible, so please keep comments professional (eg: no flaming or derogatory comments about other Members). If you do have topics that should be handled offline, please contact myself, mbizup, or jimpen at our e-e.com email addresses (i.e. JDettman@e-e.com).
Thanks,
Jim Dettman
Access Zone Advisor
Previous Discussion Thread:
https://www.experts-exchange.com/questions/27095064/Access-Experts-General-discussion-thread-for-Access-Zone-13-Jun-2011.html
Discussion topics can include (but are not limited to) Access and zone related issues, tips, tricks, news, events etc.
This thread is publically visible, so please keep comments professional (eg: no flaming or derogatory comments about other Members). If you do have topics that should be handled offline, please contact myself, mbizup, or jimpen at our e-e.com email addresses (i.e. JDettman@e-e.com).
Thanks,
Jim Dettman
Access Zone Advisor
Previous Discussion Thread:
https://www.experts-exchange.com/questions/27095064/Access-Experts-General-discussion-thread-for-Access-Zone-13-Jun-2011.html
Seems you moved the thread but not the related content ....
mx
mx
> Something one has to be aware of when dealing with dates
> prior to 1899-12-30 00:00:00
Yes indeed, as that behaviour has changed through the versions since 2.0.
However, one method is quite simple: Stay off handling date and time with anything else than data type DateTime. Always and with no exceptions; then you play safe.
You can create 1899-12-30 from a numeral, and it is that date you are creating with CDate(0), but the default behaviour of Access is to supress the _display_ of the date itself for that date.
If you expect to hold data of that date, and you need to have the date displayed, you will have to specify the format:
? Format(CDate(0),"yyyy-mm-d
1899-12-30
/gustav
> prior to 1899-12-30 00:00:00
Yes indeed, as that behaviour has changed through the versions since 2.0.
However, one method is quite simple: Stay off handling date and time with anything else than data type DateTime. Always and with no exceptions; then you play safe.
You can create 1899-12-30 from a numeral, and it is that date you are creating with CDate(0), but the default behaviour of Access is to supress the _display_ of the date itself for that date.
If you expect to hold data of that date, and you need to have the date displayed, you will have to specify the format:
? Format(CDate(0),"yyyy-mm-d
1899-12-30
/gustav
<Seems you moved the thread but not the related content ....>
mx,
Unfortunately comments can't be moved between threads.
EDIT:
Here's the beginning of the last active discussion (dates) on the old thread for reference, though:
http:Q_27095064.html#a36475668
mx,
Unfortunately comments can't be moved between threads.
EDIT:
Here's the beginning of the last active discussion (dates) on the old thread for reference, though:
http:Q_27095064.html#a36475668
I think the expression for negative datetime values would involve the fix() function in order to break up the time from the date parts of the float value
x=-1.25
?cdate(fix(x)-(1+x-fix(x)))
12/29/1899 6:00:00 PM
My biggest disappointment was discovering that the DateAdd() function won't treat floating point values properly.
aikimark: I would have expected that one day and 6 hours before midnight on 30 Dec 1899 would have been:
1899-12-28 18:00:00
1899-12-28 18:00:00
It should have been. I was playing with the expressions, trying to simplify them before posting. I guess I undid something in the process. :-(
You are really messing things up here.
1. Please carefully study (again) the explanation and the links I provided in the previous thread.
Pay close attention to the Excel graph and the related values. These explain it all.
2. A numeric date/time of -1.25 is read as -1 day +0.25 day, thus the date/time is 18 hours before 1899-12-30 00:00:00 which is 1899-12-29 06:00:00 (not 1899-12-29 18:00:00 neither 1899-12-28 18:00:00.
This is easy to check:
? CDbl(#1899-12-29 06:00:00#)
-1.25
3. Numeric values for date/time between -1 and 0 _excluding_ these integers are not defined and should be avoided at all times even though they in the later versions of Access are interpreted by the converter functions (including TimeSerial) as their absolute (positive) values.
4. > My biggest disappointment was discovering that the DateAdd() function
> won't treat floating point values properly.
It is intended for adding an integer count of a time interval to a date/time value and works very well for that purpose. Using any other data type than date/time should be considered to be at own risk.
5. If you have to use negative values as a direct measure for partial days before the date of numeric 0, use the provided functions in the previous thread for converting between native and linear time.
/gustav
1. Please carefully study (again) the explanation and the links I provided in the previous thread.
Pay close attention to the Excel graph and the related values. These explain it all.
2. A numeric date/time of -1.25 is read as -1 day +0.25 day, thus the date/time is 18 hours before 1899-12-30 00:00:00 which is 1899-12-29 06:00:00 (not 1899-12-29 18:00:00 neither 1899-12-28 18:00:00.
This is easy to check:
? CDbl(#1899-12-29 06:00:00#)
-1.25
3. Numeric values for date/time between -1 and 0 _excluding_ these integers are not defined and should be avoided at all times even though they in the later versions of Access are interpreted by the converter functions (including TimeSerial) as their absolute (positive) values.
4. > My biggest disappointment was discovering that the DateAdd() function
> won't treat floating point values properly.
It is intended for adding an integer count of a time interval to a date/time value and works very well for that purpose. Using any other data type than date/time should be considered to be at own risk.
5. If you have to use negative values as a direct measure for partial days before the date of numeric 0, use the provided functions in the previous thread for converting between native and linear time.
/gustav
DateAdd() gives me the result I expected:
? dateadd("h",-30,#1899-12-3
1899-12-28 18:00:00
anyway, "nuff said"
? dateadd("h",-30,#1899-12-3
1899-12-28 18:00:00
anyway, "nuff said"
> DateAdd() gives me the result I expected ..
Of course! That's one of the reasons why I recommend always to use the native date handling functions in favour of some "clever" method.
The only exception I can think of at the moment is to use Fix to remove the time part of a date/time value in loops or queries because it is about 100 times faster than using DateValue (and even faster in SQL where they are native functions) :
datDateOnly = DateValue(datDateWithTime)
Note that Fix and not Int must be used if you expect date values prior to 1899-12-30. For example for the value used above:
? Fix(#1899-12-29 06:00:00#)
1899-12-29
? Int(#1899-12-29 06:00:00#)
1899-12-28
/gustav
Of course! That's one of the reasons why I recommend always to use the native date handling functions in favour of some "clever" method.
The only exception I can think of at the moment is to use Fix to remove the time part of a date/time value in loops or queries because it is about 100 times faster than using DateValue (and even faster in SQL where they are native functions) :
datDateOnly = DateValue(datDateWithTime)
Note that Fix and not Int must be used if you expect date values prior to 1899-12-30. For example for the value used above:
? Fix(#1899-12-29 06:00:00#)
1899-12-29
? Int(#1899-12-29 06:00:00#)
1899-12-28
/gustav
To express this with the original -1.25 numeric value, use seconds and the number of seconds in a day.
?dateadd("s",-1.25*86400,c
12/28/1899 6:00:00 PM
This works relative to any datetime value. As I write this at 8:21:
?dateadd("s",-1.25*86400,n
9/4/2011 2:21:55 AM
It might be packaged this way
?dateadd("s",-1.25*86400,c
12/28/1899 6:00:00 PM
This works relative to any datetime value. As I write this at 8:21:
?dateadd("s",-1.25*86400,n
9/4/2011 2:21:55 AM
It might be packaged this way
Public Function RelativeDateTime(parmOffset, parmFromDate As Date) As Date
If IsNumeric(parmOffset) Then
RelativeDateTime = DateAdd("s", parmOffset * 86400, parmFromDate)
Else
RelativeDateTime = CDate(0)
Error 5
End If
End Function
Yes, with DateAdd minutes or seconds could be used as well.
However, even though the numeric parameter to DateAdd is specified as Double, it will only accept values within a Long, thus your function will only be able to return dates back to 1831-12-13 20:45:52.
If you had used minutes, you could go back to 100-1-1.
/gustav
However, even though the numeric parameter to DateAdd is specified as Double, it will only accept values within a Long, thus your function will only be able to return dates back to 1831-12-13 20:45:52.
If you had used minutes, you could go back to 100-1-1.
/gustav
So @mx,
Was your question about where did 30-Dec-1899 go answered?
It didn't go anywhere--but Access never displays the 30-Dec-1899 part of 30-Dec-1899 12:00:00 AM unless you force it to with Format()
Just playing with it now, you'll find that Access won't display the date part of any fractional number between -1 and 1 (ie 0.2 or -0.2) unless forced with Format()
Why?
To not confuse end-users that decide to store just the time in a field.
Nothing would freak a newbie out more than when they went to store a time and it actually displayed the 30-Dec-1899 part.
Of course, maybe that'd be a good thing and nobody'd store just the time :)
Now, as for the counter-intuitive result of CDate(-0.2) = CDate(0.2), MS had a choice to make.
It was either that the above counter-intuitive result would hold--but CDate(x.75) would always be some date 6:00:00 PM
OR
after some arbitrary date (grin and stick out tongue at /gustav here, joking :) CDate(x.75) would instead be 6:00:00 AM
MS chose that the time part of any DateSerial would be treated as positive so that the fractional part of any number used as a date would be displayed as the same time regardless of +/- for the Date. Ok, well enough. But it is a little mind-bending when you start thinking about the math involved with DateSerials and realize that the math doesn't follow the rules of algebra in the expected fashion.
Was your question about where did 30-Dec-1899 go answered?
It didn't go anywhere--but Access never displays the 30-Dec-1899 part of 30-Dec-1899 12:00:00 AM unless you force it to with Format()
Just playing with it now, you'll find that Access won't display the date part of any fractional number between -1 and 1 (ie 0.2 or -0.2) unless forced with Format()
Why?
To not confuse end-users that decide to store just the time in a field.
Nothing would freak a newbie out more than when they went to store a time and it actually displayed the 30-Dec-1899 part.
Of course, maybe that'd be a good thing and nobody'd store just the time :)
Now, as for the counter-intuitive result of CDate(-0.2) = CDate(0.2), MS had a choice to make.
It was either that the above counter-intuitive result would hold--but CDate(x.75) would always be some date 6:00:00 PM
OR
after some arbitrary date (grin and stick out tongue at /gustav here, joking :) CDate(x.75) would instead be 6:00:00 AM
MS chose that the time part of any DateSerial would be treated as positive so that the fractional part of any number used as a date would be displayed as the same time regardless of +/- for the Date. Ok, well enough. But it is a little mind-bending when you start thinking about the math involved with DateSerials and realize that the math doesn't follow the rules of algebra in the expected fashion.
ASKER
picked this up from another list /group:
http://www.zdnet.com/blog/microsoft/microsoft-to-focus-on-html5-and-javascript-for-office-15-extensions/10266
Something to think about...
Jim.
http://www.zdnet.com/blog/microsoft/microsoft-to-focus-on-html5-and-javascript-for-office-15-extensions/10266
Something to think about...
Jim.
<Something to think about...>
Sigh.
Javascript != fun
Looks like someone in MS still hasn't gotten the memo
Office sells BECAUSE of VBA, not despite it
The whole breathless "... and you can do it all without writing any code" declaration is barking up the wrong tree.
"You can do it all with code that is easy to generate, understand and extend" would be a happier mantra.
Sigh.
Javascript != fun
Looks like someone in MS still hasn't gotten the memo
Office sells BECAUSE of VBA, not despite it
The whole breathless "... and you can do it all without writing any code" declaration is barking up the wrong tree.
"You can do it all with code that is easy to generate, understand and extend" would be a happier mantra.
LOL
Before O2007 was in beta, I was part of a consultation group of outside users that MS was looking for feedback from. It was the beginning of the whole Sharepoint/Access integration. I couldn't see the point of it. Still can't. Said so. I asked, "What is SharePoint good for? Could somebody google me up a concise answer to that?" Besides being told it was a $1 Billion business for MS, I didn't get an answer. Googling it today doesn't really bring up a concise answer still. This was worth a belly laugh at.
http://blogs.technet.com/b/jessmeats/archive/2010/04/01/what-is-sharepoint-2010.aspx
<I usually respond to that question with one of my own. Do you want the two hour answer or then ten hour answer?>
I want the two sentence answer. The fact that it doesn't exist tells me all I really need to know--avoid
Before O2007 was in beta, I was part of a consultation group of outside users that MS was looking for feedback from. It was the beginning of the whole Sharepoint/Access integration. I couldn't see the point of it. Still can't. Said so. I asked, "What is SharePoint good for? Could somebody google me up a concise answer to that?" Besides being told it was a $1 Billion business for MS, I didn't get an answer. Googling it today doesn't really bring up a concise answer still. This was worth a belly laugh at.
http://blogs.technet.com/b/jessmeats/archive/2010/04/01/what-is-sharepoint-2010.aspx
<I usually respond to that question with one of my own. Do you want the two hour answer or then ten hour answer?>
I want the two sentence answer. The fact that it doesn't exist tells me all I really need to know--avoid
Yeah ... and DAO was going away 10 years ago. Yawn !!!
mx
mx
ASKER
<<"What is SharePoint good for? >>
It's great for workflow type applications, but Microsoft is trying to make it the be all of end all, which I don't buy.
<<Yeah ... and DAO was going away 10 years ago. Yawn !!!>>
But really it has. DAO hasn't been worked on in some time. Granted moving forward you've still been able to use it for the most part...nothing's been a real deal breaker, but there have been problems.
Record level locking is one good example. Doesn't work for DAO unless you establish a ADO connection first. And a lot of the new ACE settings are only available through the JET/ACE OLEDB provider. DAO's time is coming and has been for some time.
Personally I think VBA is next up on the list, but I think their going to find it a very uphill battle getting folks to let go of VBA.
Jim.
It's great for workflow type applications, but Microsoft is trying to make it the be all of end all, which I don't buy.
<<Yeah ... and DAO was going away 10 years ago. Yawn !!!>>
But really it has. DAO hasn't been worked on in some time. Granted moving forward you've still been able to use it for the most part...nothing's been a real deal breaker, but there have been problems.
Record level locking is one good example. Doesn't work for DAO unless you establish a ADO connection first. And a lot of the new ACE settings are only available through the JET/ACE OLEDB provider. DAO's time is coming and has been for some time.
Personally I think VBA is next up on the list, but I think their going to find it a very uphill battle getting folks to let go of VBA.
Jim.
Not so much yawning I am afraid.
DAO didn't go away, but A2002 was all focused on ADO--so that was a whole release that MS focused on something the community didn't buy into.
A2003 re-trenched, but didn't extend things much
A2007 focused on SharePoint and the Ribbon
A2010 made the Ribbon usable, but focused on macros and web-enabled databases and SharePoint.
Now apparently we are going to again focus on things that most of the professional development community finds to be a pointless at best, a likely distraction, muddying the waters or perhaps a hinderance.
We just deep-sixed data access pages.
Now we're all 'webby...let's make everything a web page' again?
Is this what the FoxPro community went through before they were eventually given the coup-de-grace?
DAO didn't go away, but A2002 was all focused on ADO--so that was a whole release that MS focused on something the community didn't buy into.
A2003 re-trenched, but didn't extend things much
A2007 focused on SharePoint and the Ribbon
A2010 made the Ribbon usable, but focused on macros and web-enabled databases and SharePoint.
Now apparently we are going to again focus on things that most of the professional development community finds to be a pointless at best, a likely distraction, muddying the waters or perhaps a hinderance.
We just deep-sixed data access pages.
Now we're all 'webby...let's make everything a web page' again?
Is this what the FoxPro community went through before they were eventually given the coup-de-grace?
"But really it has."
Really? Funny, I just used it 10 minutes ago.
Sorry, but I've heard this all before. And seriously, what are the qualifications of this talking head Mary-Jo Foley ?
mx
Really? Funny, I just used it 10 minutes ago.
Sorry, but I've heard this all before. And seriously, what are the qualifications of this talking head Mary-Jo Foley ?
mx
<And seriously, what are the qualifications of this talking head Mary-Jo Foley>
She's been around a long time.
She's not Stu Sjouwerman over at http://www.wservernews.com/
But she's also not Rob Enderly or John Dvorak either.
What she has to say is usually thoughtful and, if not always on point, never out of touch on the flank either
She's been around a long time.
She's not Stu Sjouwerman over at http://www.wservernews.com/
But she's also not Rob Enderly or John Dvorak either.
What she has to say is usually thoughtful and, if not always on point, never out of touch on the flank either
Well, the boys and girls over in the mvp DL are banging on that link as we speak, with endless opinions and discussion. And frankly, I've got much better things to do.
mx
mx
ASKER
<<Is this what the FoxPro community went through before they were eventually given the coup-de-grace? >>
Yes and no. Foxpro by far was a better tool for a serious developer. It had a lot more range then Access ever had (I've used both). But since it was a mature product, killing it off didn't have a lot of impact right off. Still, the impact of Microsoft killing it is being felt and there are a few things that developers would have like to see more work on.
Frankly I think Microsoft missed the boat; there should have started with VFP and turned it into Access. They would have gotten a lot of mileage out of a product like that.
<<"But really it has."
Really? Funny, I just used it 10 minutes ago.>>
Yeah, but I bet you didn't use record level locking did you? Considering that professional developers hammered Microsoft for a number of years for that feature, I think it significant that they did not go back and add it to DAO. That proves it's dead. Yes, that doesn't stop you from using it now, but it is dead.
<<Sorry, but I've heard this all before. And seriously, what are the qualifications of this talking head Mary-Jo Foley ?>>
No real qualifications other then she spotted a job posting at Microsoft that tips their hand on where their planning to go. Couple this with the rather significant move on their part of enchancing macros in Access, the push to the web with Sharepoint and Office 365, and it's rather obvious that Microsoft is starting to move away from VBA.
Most likely it will be a good ten to fifteen years before that will become a problem for any of us (and quite a few of us will be retired by then), but for the younger crowd just starting their careers, it's something they may want to start looking at if they don't want to get left behind.
I've even been begining to have my doubts about Access. Over the past year or so, the amount of Access related jobs being posted has declined quite a bit. It's still a favorite for many shops, but like SQL Server, other tools have made their way down to the desktop and of course are available for web programming, which so far, Access is really not capable of doing.
Jim.
Yes and no. Foxpro by far was a better tool for a serious developer. It had a lot more range then Access ever had (I've used both). But since it was a mature product, killing it off didn't have a lot of impact right off. Still, the impact of Microsoft killing it is being felt and there are a few things that developers would have like to see more work on.
Frankly I think Microsoft missed the boat; there should have started with VFP and turned it into Access. They would have gotten a lot of mileage out of a product like that.
<<"But really it has."
Really? Funny, I just used it 10 minutes ago.>>
Yeah, but I bet you didn't use record level locking did you? Considering that professional developers hammered Microsoft for a number of years for that feature, I think it significant that they did not go back and add it to DAO. That proves it's dead. Yes, that doesn't stop you from using it now, but it is dead.
<<Sorry, but I've heard this all before. And seriously, what are the qualifications of this talking head Mary-Jo Foley ?>>
No real qualifications other then she spotted a job posting at Microsoft that tips their hand on where their planning to go. Couple this with the rather significant move on their part of enchancing macros in Access, the push to the web with Sharepoint and Office 365, and it's rather obvious that Microsoft is starting to move away from VBA.
Most likely it will be a good ten to fifteen years before that will become a problem for any of us (and quite a few of us will be retired by then), but for the younger crowd just starting their careers, it's something they may want to start looking at if they don't want to get left behind.
I've even been begining to have my doubts about Access. Over the past year or so, the amount of Access related jobs being posted has declined quite a bit. It's still a favorite for many shops, but like SQL Server, other tools have made their way down to the desktop and of course are available for web programming, which so far, Access is really not capable of doing.
Jim.
"Yeah, but I bet you didn't use record level locking did you? "
So ... that's your question? And justification? Well, RL is rarely an issue for me, and I have various ways to deal with it in any critical case.
mx
So ... that's your question? And justification? Well, RL is rarely an issue for me, and I have various ways to deal with it in any critical case.
mx
ASKER
@MX,
<< And frankly, I've got much better things to do. >>
So go do it. I merely posted it as an interesting tid-bit. If you don't feel it's worth taking the time to comment, then don't bother.
Geeze louise...
Jim.
<< And frankly, I've got much better things to do. >>
So go do it. I merely posted it as an interesting tid-bit. If you don't feel it's worth taking the time to comment, then don't bother.
Geeze louise...
Jim.
Actually, I was referring to making any comments in the mvp DL.
mx
mx
A little bit more about
<Not so much yawning I am afraid.>
I think we can all agree that there are many in the enterprise who HATE Access and would like it killed.
Needless to say, we are not among those folks.
But this mis-guided focus that MS has put on Access isn't aiding our cause any.
Where is the development work on creating an upgrade path from Access to .NET?
You move from Word tables, to Excel, to Access, but then you get stuck
SaveAsText has been around for a while.
The back-ends are compatible--so why can't a form be exported to a WinForm in a VB.NET project?
It could if someone wanted to work it out--and that's MS's job.
If there was a good upgrade path OUT of Access, maybe the enterprise would be a little friendlier
Where is the focus on letting admins push policy to Access?
Naming conventions being one big one!
Max query time-outs being another.
There's other things the enterprise wants to control about Access.
Instead, it's usually outlawws because the control STILL has been provided
There are things Access needs way more than HTML5 and Javascript.
<<Not so much yawning I am afraid.>>
Steaming mad.
Focus on what's needed, not what's trendy
<Not so much yawning I am afraid.>
I think we can all agree that there are many in the enterprise who HATE Access and would like it killed.
Needless to say, we are not among those folks.
But this mis-guided focus that MS has put on Access isn't aiding our cause any.
Where is the development work on creating an upgrade path from Access to .NET?
You move from Word tables, to Excel, to Access, but then you get stuck
SaveAsText has been around for a while.
The back-ends are compatible--so why can't a form be exported to a WinForm in a VB.NET project?
It could if someone wanted to work it out--and that's MS's job.
If there was a good upgrade path OUT of Access, maybe the enterprise would be a little friendlier
Where is the focus on letting admins push policy to Access?
Naming conventions being one big one!
Max query time-outs being another.
There's other things the enterprise wants to control about Access.
Instead, it's usually outlawws because the control STILL has been provided
There are things Access needs way more than HTML5 and Javascript.
<<Not so much yawning I am afraid.>>
Steaming mad.
Focus on what's needed, not what's trendy
Discovery:
I encountered an interesting 'feature' of Access2007. When I migrated a database consolidation job from Access97 to this database on one of the client's servers, I couldn't get the scheduled task to run under an admin account. The admin account had rights to all of the folders.
Turns out that during my migration testing with my own account, I had changed some of the Access2007 (trust center) options to prevent warning messages. It was one of these warnings that prevented the (admin) started task from executing.
Is there a way for the network admin folks to establish these settings for all Access2007 users or do such options only exist at the user level?
I encountered an interesting 'feature' of Access2007. When I migrated a database consolidation job from Access97 to this database on one of the client's servers, I couldn't get the scheduled task to run under an admin account. The admin account had rights to all of the folders.
Turns out that during my migration testing with my own account, I had changed some of the Access2007 (trust center) options to prevent warning messages. It was one of these warnings that prevented the (admin) started task from executing.
Is there a way for the network admin folks to establish these settings for all Access2007 users or do such options only exist at the user level?
@mx is about to test the method noted here
https://www.experts-exchange.com/questions/27343501/Can-'trusted-locations'-be-set-via-automation.html?cid=1573&anchorAnswerId=36718207#a36718207
at the end.
Sources for the method are cited in the question.
Set up one machine entirely as you need it.
Search the registry for 'Trusted Locations'
Export the appropriate keys to .reg files
Put them in the netlogon share
add
regedit /s PathToRegFile to the logon script.
That should do it.
GPO is another method as well.
Logon scripts are useful for this because they run under SYSTEM, and most normal user accounts cannot use regedit, so this is a decent way around need admin privileges on the local box.
https://www.experts-exchange.com/questions/27343501/Can-'trusted-locations'-be-set-via-automation.html?cid=1573&anchorAnswerId=36718207#a36718207
at the end.
Sources for the method are cited in the question.
Set up one machine entirely as you need it.
Search the registry for 'Trusted Locations'
Export the appropriate keys to .reg files
Put them in the netlogon share
add
regedit /s PathToRegFile to the logon script.
That should do it.
GPO is another method as well.
Logon scripts are useful for this because they run under SYSTEM, and most normal user accounts cannot use regedit, so this is a decent way around need admin privileges on the local box.
TechRepublic editor trash talking Access
http://www.techrepublic.com/blog/10things/10-things-i-dont-miss-about-access/2758
http://www.techrepublic.com/blog/10things/10-things-i-dont-miss-about-access/2758
WOW! ...
Well, I've never been impressed with Susan Harkins anyway, so I'm not surprised. I would like to invite her to where I work to see what can *actually* be done with the highly underrated product called Microsof Access ... and at that in a multi-user WAN environment. Not to mention the numerous apps I have out in the wild (since A1.0) that work trouble free 24x7x365.
It's also kind of ironic to bad mouth a product that she has no doubt made a lot of money working with or writing about.
mx
Well, I've never been impressed with Susan Harkins anyway, so I'm not surprised. I would like to invite her to where I work to see what can *actually* be done with the highly underrated product called Microsof Access ... and at that in a multi-user WAN environment. Not to mention the numerous apps I have out in the wild (since A1.0) that work trouble free 24x7x365.
It's also kind of ironic to bad mouth a product that she has no doubt made a lot of money working with or writing about.
mx
I think it would be more effective to post responses in Susan's article comments section. That way, the FUD wouldn't go unchallenged.
Been There, Done That. Tired of justifying it. Got better things to do that I actually get paid for. It's an endless discussion anyway, just like discussing Nulls.
mx
mx
Besides, I think there is already an EE article on the merits vs myths of Access.
"I think it would be more effective to post responses in Susan's article comments section."
Yeah ... but it's a No Win discussion. Elements of what she says are certainly true. But some of us that actually figured out how to use the product and think outside the (Access) box ... were able to go way beyond all the BS she is tossing out.
mx
Yeah ... but it's a No Win discussion. Elements of what she says are certainly true. But some of us that actually figured out how to use the product and think outside the (Access) box ... were able to go way beyond all the BS she is tossing out.
mx
And ANYTHING bad she said about Access can be attested to ANY other product/platform ... THAT ... is for SURE.
mx
mx
FWIW, it's posted there
<Really,
To have made up 10 points like you have, you must not be actually using Access anymore. #1 hasn't been a problem since Access 2003.
#2, 3 and 6 are just the author disliking bigots. I dislike them too--but they aren't three separate points.
While the new Office 2010 help is almost useless, the Access 2003 VBA help was very good, and what you couldn't find, you could Google. Access has a VERY robust community surrounding it. VBA in general does. What you can't figure out for yourself, you can very likely get someone to give you a hand with at sites like Experts Exchange and Utter Access. The Access Web is another outstanding site, as are Allen Browne's site and, though he no longer maintains it, Stephen Lebans.
Try getting that level of help on something like SharePoint. Fuggetaboutit!
The author admits that point #7 is rarely a problem anymore.
So that leaves #5, 8, 9 and 10
#10 is a self-inflicted wound. If you don't like wizard-code, don't use wizards. If someone else's wizard-code annoys you--well that's #5--and I will certainly agree that maintain SOMEONE ELSE'S code is a bugger. Especially if they are amateurs...but what does that have to do with Access specifically? Maintaining amateur ANYTHING is a bugger. VBA, javascript, HTML, ASP, you name it. No Fun! And #8 and 9 are really the same thing, too. It's no fun to clean up a mess.
Alright, so we are left with an article that says the author doesn't miss the fact that Access attracts the ire of bigots and can be used by amateurs. True enough.
Next time, Susan, try and post something a little more substantial about how the bigots could be de-fanged and the amateurs reined in, guided and taught best practices.
>
<Really,
To have made up 10 points like you have, you must not be actually using Access anymore. #1 hasn't been a problem since Access 2003.
#2, 3 and 6 are just the author disliking bigots. I dislike them too--but they aren't three separate points.
While the new Office 2010 help is almost useless, the Access 2003 VBA help was very good, and what you couldn't find, you could Google. Access has a VERY robust community surrounding it. VBA in general does. What you can't figure out for yourself, you can very likely get someone to give you a hand with at sites like Experts Exchange and Utter Access. The Access Web is another outstanding site, as are Allen Browne's site and, though he no longer maintains it, Stephen Lebans.
Try getting that level of help on something like SharePoint. Fuggetaboutit!
The author admits that point #7 is rarely a problem anymore.
So that leaves #5, 8, 9 and 10
#10 is a self-inflicted wound. If you don't like wizard-code, don't use wizards. If someone else's wizard-code annoys you--well that's #5--and I will certainly agree that maintain SOMEONE ELSE'S code is a bugger. Especially if they are amateurs...but what does that have to do with Access specifically? Maintaining amateur ANYTHING is a bugger. VBA, javascript, HTML, ASP, you name it. No Fun! And #8 and 9 are really the same thing, too. It's no fun to clean up a mess.
Alright, so we are left with an article that says the author doesn't miss the fact that Access attracts the ire of bigots and can be used by amateurs. True enough.
Next time, Susan, try and post something a little more substantial about how the bigots could be de-fanged and the amateurs reined in, guided and taught best practices.
>
<It's an endless discussion anyway, just like discussing Nulls.>
The latest one was an interesting discussion though..til it descended into farce.
And even then it stayed informative til almost the end.
Sometimes the audience and the players change <grin>
The latest one was an interesting discussion though..til it descended into farce.
And even then it stayed informative til almost the end.
Sometimes the audience and the players change <grin>
Sounds like you didn't read that article.
Susan doesn't trash Access, she regrets the direction it has taken - away from a development tool to a user tool and/or SharePoint frontend. I don't agree in every 10 commends but the picture is right.
I've been developing in Access since version 2.0 but stopped using it in year 2007 for new development. For developing apps Access is a dead end with no focus from MSFT.
I turned to Visual Studio 2005 and C#, then 2008 and 2010, and have never looked back. VS is a real tool for developers and you feel the focus from MSFT. Most important to me: It brings back the fun of programming. Lots of challenges too, I know, but that is what keeps you young.
/gustav
Susan doesn't trash Access, she regrets the direction it has taken - away from a development tool to a user tool and/or SharePoint frontend. I don't agree in every 10 commends but the picture is right.
I've been developing in Access since version 2.0 but stopped using it in year 2007 for new development. For developing apps Access is a dead end with no focus from MSFT.
I turned to Visual Studio 2005 and C#, then 2008 and 2010, and have never looked back. VS is a real tool for developers and you feel the focus from MSFT. Most important to me: It brings back the fun of programming. Lots of challenges too, I know, but that is what keeps you young.
/gustav
ASKER
I think you guys missed the point of the article. I have to say I agree with her on most of those points.
Jim
Jim
I'm sorry, but it gives the wrong impression, no matter what the intent.
mx
mx
I read the article.
She made two points.
She doesn't miss the bigots and she doesn't miss cleaning up after amateurs.
I thouroughly agree with her on both those points.
<VS is a real tool for developers and you feel the focus from MSFT>
VBA and Access are real tools for developers too, but I DON'T feel the focus from MSFT.
I could do a 'Top 10 MS Access needful features/continuing annoyances', too:
10. Wizard code that hasn't been updated since at least Access 97, doesn't use current syntax (RunCommand anyone), and doesn't pop out commented
9. The uselessness of the Access 2010 help file
8. The uselessness of Bing in trying to search for any VBA error ID's
7. That IsBroken is a useless thing to fix VBA references when you know you are going to break a reference
6. The continued poor documentation of how to create custom control/field formats
5. The inability to import a Word document as the 'template' of a report
4. The inability to have multiple developers work on the same file (Visual Source Safe, anyone)
3. The continued inability to define and enforce naming conventions in domain environments (let's call this field Name and this one Date!)
2. The inability to upsize an Access app to VB.NET through a tool rather than a complete redesign
1. The inability to set granular Group Policy on Access (BE must be on SQL or SQL Express, on this server, query time outs of x seconds, server utilization by a single Access user/app throttled, each procedure must have x lines of comment code, no SQL reserved words may be used, and on and on)
I don't have a soapbox and I don't get paid. I'd like those who'd have a soapbox and get paid to use it to use it to focus MSFT on the needs of the professional developer in the enterprise, and not be posting stuff of 'Thank god, it's dying' or 'Back in the day I used Access, but folks who do that are getting thin on the ground'
It's still the best RAD platform around. The FoxPro folks may argue that--but then MSFT has killed their platform off.
<I turned to Visual Studio 2005 and C#, then 2008 and 2010, and have never looked back.>
I've looked at VSEE 2005, 2008 and 2010 with VB.NET and I keep looking back, because I find that environment just too damn difficult
<Lots of challenges too, I know, but that is what keeps you young.>
Too many challenges, and that's what keeps me in VBA/Access/SQL Server Express.
I don't want to end up like the FoxPro folks.
She made two points.
She doesn't miss the bigots and she doesn't miss cleaning up after amateurs.
I thouroughly agree with her on both those points.
<VS is a real tool for developers and you feel the focus from MSFT>
VBA and Access are real tools for developers too, but I DON'T feel the focus from MSFT.
I could do a 'Top 10 MS Access needful features/continuing annoyances', too:
10. Wizard code that hasn't been updated since at least Access 97, doesn't use current syntax (RunCommand anyone), and doesn't pop out commented
9. The uselessness of the Access 2010 help file
8. The uselessness of Bing in trying to search for any VBA error ID's
7. That IsBroken is a useless thing to fix VBA references when you know you are going to break a reference
6. The continued poor documentation of how to create custom control/field formats
5. The inability to import a Word document as the 'template' of a report
4. The inability to have multiple developers work on the same file (Visual Source Safe, anyone)
3. The continued inability to define and enforce naming conventions in domain environments (let's call this field Name and this one Date!)
2. The inability to upsize an Access app to VB.NET through a tool rather than a complete redesign
1. The inability to set granular Group Policy on Access (BE must be on SQL or SQL Express, on this server, query time outs of x seconds, server utilization by a single Access user/app throttled, each procedure must have x lines of comment code, no SQL reserved words may be used, and on and on)
I don't have a soapbox and I don't get paid. I'd like those who'd have a soapbox and get paid to use it to use it to focus MSFT on the needs of the professional developer in the enterprise, and not be posting stuff of 'Thank god, it's dying' or 'Back in the day I used Access, but folks who do that are getting thin on the ground'
It's still the best RAD platform around. The FoxPro folks may argue that--but then MSFT has killed their platform off.
<I turned to Visual Studio 2005 and C#, then 2008 and 2010, and have never looked back.>
I've looked at VSEE 2005, 2008 and 2010 with VB.NET and I keep looking back, because I find that environment just too damn difficult
<Lots of challenges too, I know, but that is what keeps you young.>
Too many challenges, and that's what keeps me in VBA/Access/SQL Server Express.
I don't want to end up like the FoxPro folks.
I tend to agree with Jim and gustav. I see her article as more of a lamentation on the way Access has been going (or NOT going) rather than a full out trashing. There's plenty of that stuff around, and in fact much of her article is simply a regurgitation of the same-old-same-old we hear every day.
The focus of Access is on the enduser and NOT the developer, and I don't think that's going to change. MSFT doesn't view Access as a developer tool, and therefore the focus of their changes is NOT on the developer community, but rather on the end user. That's obvious, given the advent of the ribbon, MVF and Attachment fields in 2007. Developers tend to hate these, but the average user likes them (ribbon aside, in some cases).
I fully agree with gustav regarding Visual Studio. I found it daunting when I first opened it up back in 2005, but have quickly become to MUCH prefer it over the development environment in Access. The great thing about VS is you can use as much or as little of the environment as you need. I'm working on 2 projects in Access 2010 now, and find myself frowning when the VBA environment doesn't do the things VS does (and wishing I could develop Access in VS!).
The focus of Access is on the enduser and NOT the developer, and I don't think that's going to change. MSFT doesn't view Access as a developer tool, and therefore the focus of their changes is NOT on the developer community, but rather on the end user. That's obvious, given the advent of the ribbon, MVF and Attachment fields in 2007. Developers tend to hate these, but the average user likes them (ribbon aside, in some cases).
I fully agree with gustav regarding Visual Studio. I found it daunting when I first opened it up back in 2005, but have quickly become to MUCH prefer it over the development environment in Access. The great thing about VS is you can use as much or as little of the environment as you need. I'm working on 2 projects in Access 2010 now, and find myself frowning when the VBA environment doesn't do the things VS does (and wishing I could develop Access in VS!).
ASKER
<<I fully agree with gustav regarding Visual Studio. I found it daunting when I first opened it up back in 2005, but have quickly become to MUCH prefer it over the development environment in Access. >>
Also don't forget about Lightswitch, which I believe at some point will become Microsoft's light weight/RAD app development tool for developers.
Personally what I see on the horizon is Access being simplified with more focus on the end-user. VBA will disappear from Office at some point and macros will rein once again. That will be a tough sell with the Excel crowd, but for Access? Probably not with the direction its taken. In fact I think your already starting to see it happen with the focus being made with web apps and Sharepoint.
And anyone that thinks I'm wrong, take a look at the amount of effort that was put into the new macro editor (and BTW - anyone notice that it looks like it's based off an XML file?) and taking care of the problems that macro's had (ie. lack of error handling). Even as early as 2003 they started pushing towards the use of macro's because of "security issues" with VBA.
Won't be any shock to me to see VBA disappear.
I want to go back and re-read Susan's article, but for me it was right on.
Jim.
Also don't forget about Lightswitch, which I believe at some point will become Microsoft's light weight/RAD app development tool for developers.
Personally what I see on the horizon is Access being simplified with more focus on the end-user. VBA will disappear from Office at some point and macros will rein once again. That will be a tough sell with the Excel crowd, but for Access? Probably not with the direction its taken. In fact I think your already starting to see it happen with the focus being made with web apps and Sharepoint.
And anyone that thinks I'm wrong, take a look at the amount of effort that was put into the new macro editor (and BTW - anyone notice that it looks like it's based off an XML file?) and taking care of the problems that macro's had (ie. lack of error handling). Even as early as 2003 they started pushing towards the use of macro's because of "security issues" with VBA.
Won't be any shock to me to see VBA disappear.
I want to go back and re-read Susan's article, but for me it was right on.
Jim.
ASKER
OK quick poll; what do you thing the #1 Access question is that we see around here?
I think it's a toss up between:
"How do I compile my Access DB into an EXE?".
and
"My DB is corrupt; what do I do now?"
Inquiring minds want to know...
Jim.
I think it's a toss up between:
"How do I compile my Access DB into an EXE?".
and
"My DB is corrupt; what do I do now?"
Inquiring minds want to know...
Jim.
Another close first is:
"How do I put my Access database on the Web?"
as well as:
"What is causing this error?"
and not far behind:
(what is causing this) "Type Mismatch"
mx
"How do I put my Access database on the Web?"
as well as:
"What is causing this error?"
and not far behind:
(what is causing this) "Type Mismatch"
mx
One of these seems to come up almost every day:
- Error 3061 Too Few Parameters (often followed in the same thread by 3075 - missing operator)
- Type mismatch errors
- Invalid use of Null
- Error 3061 Too Few Parameters (often followed in the same thread by 3075 - missing operator)
- Type mismatch errors
- Invalid use of Null
I've answered 305 questions.
I don't think more than 5 have been on any one single topic.
Top 3 topics that stick out:
1. Something that boils down to 'Am I normal?" after looking at it, because some form/report/query ain't working.
2. I am using dates and they ain't working right?
3. How do I Password protect/secure something in Access?
Steve Jobs has passed on.
I joke about how the guy who invented CD plastic wraps is in Purgatory with nothing sharp, no teeth and no fingernails trying to open CD's
Or the bastard who invented child-proof caps is in Purgatory with arthritis trying to open a bottle of Aspirin
Or the woman who invented fuzzy toilet seat covers is now a man in Purgatory standing in front of a toilet seat that falls down just when he starts to piss
Steve Jobs is in Purgatory suffering through all the "It's simple, it's intuitive, it just works" things that don't.
That includes using iPods on Pentium class Windows machines where Windows sees the iPod--but iTunes won't.
Or using iTunes on Windows period
And all the other 'simple' stuff that Steve inspired, that makes life hell for the rest of us. (like automatic code generation)
That would include all pain suffered by those who have to deal with the results of folks trying to build databases without the slightest clue about data normalization.
I don't think more than 5 have been on any one single topic.
Top 3 topics that stick out:
1. Something that boils down to 'Am I normal?" after looking at it, because some form/report/query ain't working.
2. I am using dates and they ain't working right?
3. How do I Password protect/secure something in Access?
Steve Jobs has passed on.
I joke about how the guy who invented CD plastic wraps is in Purgatory with nothing sharp, no teeth and no fingernails trying to open CD's
Or the bastard who invented child-proof caps is in Purgatory with arthritis trying to open a bottle of Aspirin
Or the woman who invented fuzzy toilet seat covers is now a man in Purgatory standing in front of a toilet seat that falls down just when he starts to piss
Steve Jobs is in Purgatory suffering through all the "It's simple, it's intuitive, it just works" things that don't.
That includes using iPods on Pentium class Windows machines where Windows sees the iPod--but iTunes won't.
Or using iTunes on Windows period
And all the other 'simple' stuff that Steve inspired, that makes life hell for the rest of us. (like automatic code generation)
That would include all pain suffered by those who have to deal with the results of folks trying to build databases without the slightest clue about data normalization.
I like it:-)
Tying the gloom of Susan Harkins post together with the death of Steve Jobs, here's this post
http://www.sswug.org/editorials/default.aspx?id=2315
OLE DB is headed for the scrap heap. That's what .adp's use, right?
So the dumbing down of Access takes another step as the folks who were using .adp's tended to be the enterprise guys.
Don't be surprised if the next version of Access doesn't support .adp's
How does that tie together with Jobs?
WebMatrix, LightSwitch, Access templates, SharePoint, the 'Cloud'
"Look, you built a whole app AND YOU DIDN'T EVEN HAVE TO WRITE ANY CODE!"
That crap is all a result of Jobs and the reality distortion field.
Maybe with his passing, we can start to put that behind us.
IT has to be logical, memorable, teachable and learnable.
IT is never going to simple--unless you let someone do all your thinking for you--and the God help you if you need to do something for yourself.
Rest in Peace, Steve Jobs, but I for one will NOT miss your influence on the world of IT
You may have pushed MSFT to be better than it would have been, but for the most part your stuff was middling hardware running inside a very pretty box.
The software stack was absolute garbage with an outstanding UI marketed with unparalleled skill.
Palm yesterday, RIM today, and Apple the day after next Tuesday.
Pretty toys, useful toys, replaceable toys--but toys. And toys get replaced by the next fad.
http://www.sswug.org/editorials/default.aspx?id=2315
OLE DB is headed for the scrap heap. That's what .adp's use, right?
So the dumbing down of Access takes another step as the folks who were using .adp's tended to be the enterprise guys.
Don't be surprised if the next version of Access doesn't support .adp's
How does that tie together with Jobs?
WebMatrix, LightSwitch, Access templates, SharePoint, the 'Cloud'
"Look, you built a whole app AND YOU DIDN'T EVEN HAVE TO WRITE ANY CODE!"
That crap is all a result of Jobs and the reality distortion field.
Maybe with his passing, we can start to put that behind us.
IT has to be logical, memorable, teachable and learnable.
IT is never going to simple--unless you let someone do all your thinking for you--and the God help you if you need to do something for yourself.
Rest in Peace, Steve Jobs, but I for one will NOT miss your influence on the world of IT
You may have pushed MSFT to be better than it would have been, but for the most part your stuff was middling hardware running inside a very pretty box.
The software stack was absolute garbage with an outstanding UI marketed with unparalleled skill.
Palm yesterday, RIM today, and Apple the day after next Tuesday.
Pretty toys, useful toys, replaceable toys--but toys. And toys get replaced by the next fad.
ASKER
Thanks for those ideas. I will think them over. Probably should explain a bit. I got asked if I'd be willing to fill-in as the guest speaker for the next EE podcast (the original speaker had to bow out due to work constraints).
One of the segments in the Podcasts is a "question of the week", which actually I was hoping we might do as a regular thing, but through webinar's. Kind of an "Access Answers column" where an Expert (or panel of them) hit the top x questions. This more or less dove tails back into the idea of Expert discussion threads we discussed here some time ago. I haven't forgotten about those, but every time I think them through, I realize that the question/comment approach does not work all that well for a lot of it. I think Podcasts and Webinar's would be a better fit. Podcasts for things like “Should I use NULLs in my app?” and Webinar's for the “How do I?” type questions as you can actually demonstrate what your talking about.
However I found out yesterday that EE only likes to do about one a month. Not sure if that's chiseled in stone or not or basically just a matter of resources at the moment.
But for the Podcast, I need something that can simply be talked about in the span of five minutes or so and be made clear.
Normalization is something that certainly comes up often enough, but it's too complex of a subject to do in a Podcast. It also happens to be the topic of a Webinar that I will be doing, which is scheduled for Nov 3rd. And BTW, if anyone has an hour to kill and would like to sit in on the practice run and critique at the end, I will be doing that Oct 25th 2:00 pm ET/11:00 am PT.
Jim.
@Jim
What is the level of your audience?
You might consider presenting table joins and then show a self-join example.
What is the level of your audience?
You might consider presenting table joins and then show a self-join example.
ASKER
<<What is the level of your audience?>>
Intro/Beginner. I want people to be able to get off on the right foot. That way, if they get in over their heads, it makes our job easier and it doesn't cost them an arm and a leg to have it re-done. Plus we don't end up with questions like "Why does Access allow only 255 fields in a table?"
<<You might consider presenting table joins and then show a self-join example. >>
I plan to touch on joins, but only the simple ones; inner and outer. Between talking about application design in general, explaining normalization, relationships, and the simple joins, I'll have more then enough to talk about in a 30-45 time frame.
I'd post the outline, but it's not yet complete. This is more or less another last minute thing. I had intended on doing one, just not quite so soon.
Jim.
Intro/Beginner. I want people to be able to get off on the right foot. That way, if they get in over their heads, it makes our job easier and it doesn't cost them an arm and a leg to have it re-done. Plus we don't end up with questions like "Why does Access allow only 255 fields in a table?"
<<You might consider presenting table joins and then show a self-join example. >>
I plan to touch on joins, but only the simple ones; inner and outer. Between talking about application design in general, explaining normalization, relationships, and the simple joins, I'll have more then enough to talk about in a 30-45 time frame.
I'd post the outline, but it's not yet complete. This is more or less another last minute thing. I had intended on doing one, just not quite so soon.
Jim.
a self join can be inner or left.
Also, I find that people don't know that a query can be used as a row source, just like a table, when creating queries. If you introduce a Group By query, showing a group sum, then you can go back and join that Group By query to the raw data and calculate the group percentage for each row. Sometimes you don't need a report.
Also, I find that people don't know that a query can be used as a row source, just like a table, when creating queries. If you introduce a Group By query, showing a group sum, then you can go back and join that Group By query to the raw data and calculate the group percentage for each row. Sometimes you don't need a report.
The good normalization tutorial that used to be at http://www.phlonx.com/resources/nf3/ was gone for a bit as the webname expired.
I see that it's back up this morning.
It's what I found myself back in the day, and what I point newcomers at when the inevitable normalization questions come up.
I see that it's back up this morning.
It's what I found myself back in the day, and what I point newcomers at when the inevitable normalization questions come up.
A spin off on Jim's question...
I think the "#1 neglected Access question that we see around here", in Designated Expert alerts and pinned to the top of the Zone Landing page involves web databases and/or mixing Sharepoint with Access 2010.
I think the "#1 neglected Access question that we see around here", in Designated Expert alerts and pinned to the top of the Zone Landing page involves web databases and/or mixing Sharepoint with Access 2010.
<web databases and/or mixing Sharepoint with Access 2010.>
Those wind up neglected because I don't think anyone is doing that kind of stuff
Back in the pre-beta Access 2007 discussion phase, I asked MSFT to give me a good answer to
"What is SharePoint good for" I never got an answer. "It's a $1 Billion business"
Now when you google that phrase at least something comes up
http://www.dylanwolf.com/programming/131/
But most of the answers range from 'nothing' to 'well, it's a good document repository system'
None of that truly jives with Access. You use reports and a database to eliminate separate documents, making a repository system redundant.
I never got why MS was so keen to push Access/SharePoint integration. There's just no point to it.
Access's backend should--and does--go to SQL server, not SharePoint.
And if you want a web front end, well then you don't need Access.
I'd dearly love a way to 'upgrade' an Access front-end to Visual Web Developer or VB.NET.
I don't know that I'll ever get one with MSFT's focus on dumbing down and de-VBA-ing Access
SharePoint is a dead-end in too many ways for most Experts in Access to be messing with it.
Those wind up neglected because I don't think anyone is doing that kind of stuff
Back in the pre-beta Access 2007 discussion phase, I asked MSFT to give me a good answer to
"What is SharePoint good for" I never got an answer. "It's a $1 Billion business"
Now when you google that phrase at least something comes up
http://www.dylanwolf.com/programming/131/
But most of the answers range from 'nothing' to 'well, it's a good document repository system'
None of that truly jives with Access. You use reports and a database to eliminate separate documents, making a repository system redundant.
I never got why MS was so keen to push Access/SharePoint integration. There's just no point to it.
Access's backend should--and does--go to SQL server, not SharePoint.
And if you want a web front end, well then you don't need Access.
I'd dearly love a way to 'upgrade' an Access front-end to Visual Web Developer or VB.NET.
I don't know that I'll ever get one with MSFT's focus on dumbing down and de-VBA-ing Access
SharePoint is a dead-end in too many ways for most Experts in Access to be messing with it.
It wouldn't surprise me if those questions start getting picked up more regularly as people (Access Newbies) start learning Access through Access 2010 versus earlier versions.
I think a lot of us (regulars) are a bit set in our ways - I know I am. I remember a similar situation with Access 2007 questions, particularly those involving the Ribbon. They weren't necessarily difficult questions - we just didn't have many people in the core group of Access Experts at the time who were familiar with the Ribbon. It took a while, but the number of neglected Access 2007 specific questions decreased as we got more familiar with that version, and as we picked up Experts who were trained or otherwise started out on Access 2007.
I think a lot of us (regulars) are a bit set in our ways - I know I am. I remember a similar situation with Access 2007 questions, particularly those involving the Ribbon. They weren't necessarily difficult questions - we just didn't have many people in the core group of Access Experts at the time who were familiar with the Ribbon. It took a while, but the number of neglected Access 2007 specific questions decreased as we got more familiar with that version, and as we picked up Experts who were trained or otherwise started out on Access 2007.
<It wouldn't surprise me if those questions start getting picked up more regularly>
The initial upper 'soft limit for entries in a SharePoint list linke to Access was 50,000
It hasn't changed much.
And there's no upgrade path.
And no VBA, only the new enhanced macros
There'll be folks who do it. I hear Albert Kallal is big on this stuff.
But there won't be many.
It's like multi-valued fields, storing images and files in the db and steering your car with your feet.
You can do it, but it's not a good idea.
The initial upper 'soft limit for entries in a SharePoint list linke to Access was 50,000
It hasn't changed much.
And there's no upgrade path.
And no VBA, only the new enhanced macros
There'll be folks who do it. I hear Albert Kallal is big on this stuff.
But there won't be many.
It's like multi-valued fields, storing images and files in the db and steering your car with your feet.
You can do it, but it's not a good idea.
"I hear Albert Kallal is big on this stuff."
Yeah ... and the Ribbon also. And Multi-Valued Fields. But from what I see, he is one of the very few.
mx
Yeah ... and the Ribbon also. And Multi-Valued Fields. But from what I see, he is one of the very few.
mx
"But from what I see, he is one of the very few."
Forgot to add: "... contrary to what HE thinks"
Forgot to add: "... contrary to what HE thinks"
Re Miriam's most recent remark - I've caved and now have Office 2010 on my wife's laptop - when I need it ;-) ran up stairs just once in the last three months
Toy of the week:
Pesky users!
They want to send a whack of files way bigger than 15 MB
And I am not creating an FTP site.
It'd be nice to create something so they could link in all the files they need to push out to a webpage.
And then send an email notification to the people that need the files.
Ok!
Open a share with appropriate permissions on the web server, dump the two boilerplate html files in it, and give 'er
bigemails.zip
Pesky users!
They want to send a whack of files way bigger than 15 MB
And I am not creating an FTP site.
It'd be nice to create something so they could link in all the files they need to push out to a webpage.
And then send an email notification to the people that need the files.
Ok!
Open a share with appropriate permissions on the web server, dump the two boilerplate html files in it, and give 'er
bigemails.zip
ASKER
Saw this link and found it interesting:
http://msdn.microsoft.com/en-us/office/hh360994
What's missing? Access. Call me crazy, but I think it's another sign that VBA in Access is on it's way out.
Jim.
Jim, definitely...
I noticed this a while back too -
Microsoft Answers *does* have an Access area, but it takea a lot more digging to find it. The other Office products are prominently shown:
http://answers.microsoft.com/en-us/office
Question for any of the Admins subscribed here... :-)
Where does the Access zone currently rank at EE? When I started posting at EE in 2005, I believe it was the 4th most used zone.
I noticed this a while back too -
Microsoft Answers *does* have an Access area, but it takea a lot more digging to find it. The other Office products are prominently shown:
http://answers.microsoft.com/en-us/office
Question for any of the Admins subscribed here... :-)
Where does the Access zone currently rank at EE? When I started posting at EE in 2005, I believe it was the 4th most used zone.
>> I think it's another sign that VBA in Access is on it's way out.
Or is it that "VBA and Access are on their way out"?
The way MS is downplaying its own product just makes me wonder.
Or is it that "VBA and Access are on their way out"?
The way MS is downplaying its own product just makes me wonder.
ASKER
<<
Or is it that "VBA and Access are on their way out"?
The way MS is downplaying its own product just makes me wonder.
>>
Well it is 19 years old at this point, so it's fairly mature. But with the amount of effort they've put into it with 2010 and SharePoint, I would be surprised to see it disappear entirely.
I do believe strongly however that they are re-positioning it solidly in the end user camp and will be looking to move developers to Lightswitch or VS.
They also seem to be taking a harder stance towards VB6 and of course VB6 and VBA are close siblings. Given that, I don’t find it far fetched to think that VBA will disappear.
I still can’t figure out the plan with Excel though. Removing VBA from that would be a very tough sell, so all the puzzle pieces are not in place yet.
Jim.
Or is it that "VBA and Access are on their way out"?
The way MS is downplaying its own product just makes me wonder.
>>
Well it is 19 years old at this point, so it's fairly mature. But with the amount of effort they've put into it with 2010 and SharePoint, I would be surprised to see it disappear entirely.
I do believe strongly however that they are re-positioning it solidly in the end user camp and will be looking to move developers to Lightswitch or VS.
They also seem to be taking a harder stance towards VB6 and of course VB6 and VBA are close siblings. Given that, I don’t find it far fetched to think that VBA will disappear.
I still can’t figure out the plan with Excel though. Removing VBA from that would be a very tough sell, so all the puzzle pieces are not in place yet.
Jim.
Keeping in mind that Gates originally had the goal of making Office apps talk to each other using VBA, and that has happened, take VBA away and then what?
The end of VBA would be the end of Office. If you can't customize it, why would you pay for it. OpenOffice would get a sinificant uptick. The one version of Office for Mac had no VBA support. It didn't sell. The next version had VBA support again. 64 bit VBA version is nominally 7.0. MSFT is just lost. I miss Gates. Ballmer makes money--but there is just no vision about how the ecosystem is going to evolve. Sorry, phones and tablets are toys. The PC isn't going anywhere. The cloud isn't the future. It's a piece of the puzzle, not a replacement for the LAN. Sigh.
ASKER
<<Keeping in mind that Gates originally had the goal of making Office apps talk to each other using VBA, and that has happened, take VBA away and then what? >>
Strictly speaking that's OLE automation, not VBA. And you can always build interfaces to support communication. Look at Access 2010 and SharePoint; no VBA used to make that happen and no VBA code even allowed in a web DB!
Or even take ADP's; Access is a FE for SQL Server and there's no code needed to support that.
Having VBA is not an absolute requirement for apps to communicate with one another.
Jim.
Strictly speaking that's OLE automation, not VBA. And you can always build interfaces to support communication. Look at Access 2010 and SharePoint; no VBA used to make that happen and no VBA code even allowed in a web DB!
Or even take ADP's; Access is a FE for SQL Server and there's no code needed to support that.
Having VBA is not an absolute requirement for apps to communicate with one another.
Jim.
<The end of VBA would be the end of Office.>
The overwhelming majority of users never even open the VBA editor, and never have any need to do so. They open their application - whether that would be Access, Excel or otherwise - and do their work, and that's the end of it. The end of VBA would end Access as a "development" tool, but that would be about the extent of it, and MSFT seems to have been moving that way for some time. You'd still have macros and such (which are used far more often than VBA) and the typical end user would not really notice if VBA were available or not.
The overwhelming majority of users never even open the VBA editor, and never have any need to do so. They open their application - whether that would be Access, Excel or otherwise - and do their work, and that's the end of it. The end of VBA would end Access as a "development" tool, but that would be about the extent of it, and MSFT seems to have been moving that way for some time. You'd still have macros and such (which are used far more often than VBA) and the typical end user would not really notice if VBA were available or not.
The overwhelming majority of users never even open the VBA editor, and never have any need to do so.
Note that you are referring to users. The reason for that is we, the developers, open it an use it extensively. I don't want my end-users opening VBA windows. I want the user to have a seamless experience so that I don't have to be called.
But without a VBA for us developers, we have no commitment to VB or the Office suite. We are then free to find another language or develop full apps independently. We can then output our data to RTF, or csv, or XML. The developer needs to find the common interface for data they need to move.
At EE I have seen everything from Excel as a DB to a full SQL server dumping data to Word or Excel. Why would I choose something I have to pay for when I can use a free app (OpenOffice) and something like FireBird?
OLE is not a true answer. I have to output my data to a CSV to import it into many apps. They aren't M$ apps.
Note that you are referring to users. The reason for that is we, the developers, open it an use it extensively. I don't want my end-users opening VBA windows. I want the user to have a seamless experience so that I don't have to be called.
But without a VBA for us developers, we have no commitment to VB or the Office suite. We are then free to find another language or develop full apps independently. We can then output our data to RTF, or csv, or XML. The developer needs to find the common interface for data they need to move.
At EE I have seen everything from Excel as a DB to a full SQL server dumping data to Word or Excel. Why would I choose something I have to pay for when I can use a free app (OpenOffice) and something like FireBird?
OLE is not a true answer. I have to output my data to a CSV to import it into many apps. They aren't M$ apps.
"Note that you are referring to users"
Yes, that's right - and my point above was that the USER is quite obviously the focus that Microsoft has in regard to Access (and all other Office apps), and not the developer. Just look at the recent changes in Access (Ribbons, MVF's and Attachment fields) and there's little doubt that the focus of Access/Excel/Word is on the end user, and not the developer. I don't really have a problem with that - I long ago began the learning shift to .NET, and do more dev work in VS than in Access these days - but it's short sighted to presume that MSFT will always have the best interest of the developer at heart.
From my perspective, it almost seems as if Access has always occupied the middle ground in regard to the user experience, somewhere between a true user app and a development platform. From the user's standpoint you really can't do much with Access right out of the box. You have to learn the ins-and-outs of database design, form design, etc etc in order to utilize the full potential of Access. That stands in conravention to the other Office products, which are quite useful directly after installing. I think that's why we often MSFT seem to wobble in regard to their "support" for the Access development world - they are trying to make Access fit in with the other Office products, and it's just not a simple thing to do.
Finally: I've always been of the mindset that MSFT "supports" development in Access simply because it's not too terribly difficult to do so. If they thought for a second that they could gain market share by removing VBA from Access, there is little doubt in my mind that we would quickly see an end to it. In fact, as others have said, the focus on the "dev" side of Access recently has been in data macros and the shift to the web apps - those are hardly a step forward from a developer's standpoint, but the end user is generally very excited about them.
Yes, that's right - and my point above was that the USER is quite obviously the focus that Microsoft has in regard to Access (and all other Office apps), and not the developer. Just look at the recent changes in Access (Ribbons, MVF's and Attachment fields) and there's little doubt that the focus of Access/Excel/Word is on the end user, and not the developer. I don't really have a problem with that - I long ago began the learning shift to .NET, and do more dev work in VS than in Access these days - but it's short sighted to presume that MSFT will always have the best interest of the developer at heart.
From my perspective, it almost seems as if Access has always occupied the middle ground in regard to the user experience, somewhere between a true user app and a development platform. From the user's standpoint you really can't do much with Access right out of the box. You have to learn the ins-and-outs of database design, form design, etc etc in order to utilize the full potential of Access. That stands in conravention to the other Office products, which are quite useful directly after installing. I think that's why we often MSFT seem to wobble in regard to their "support" for the Access development world - they are trying to make Access fit in with the other Office products, and it's just not a simple thing to do.
Finally: I've always been of the mindset that MSFT "supports" development in Access simply because it's not too terribly difficult to do so. If they thought for a second that they could gain market share by removing VBA from Access, there is little doubt in my mind that we would quickly see an end to it. In fact, as others have said, the focus on the "dev" side of Access recently has been in data macros and the shift to the web apps - those are hardly a step forward from a developer's standpoint, but the end user is generally very excited about them.
<Just look at the recent changes in Access (Ribbons, MVF's and Attachment fields) >
Those last two have to do with SharePoint integration--which nobody looking at an app with any kind of growth curve thinks is a good idea.
50000 items to a lsit and no upgrade path are complete show stoppers for any serious app.
<but it's short sighted to presume that MSFT will always have the best interest of the developer at heart.>
A platform without developers is dead. Developers aren't the only thing a platform needs, by a long shot, but they are an essential ingredient.
<You have to learn the ins-and-outs of database design, form design, etc etc in order to utilize the full potential of Access. >
Absolutely. Which means that it's the intemediate step between Excel, with its formulas, initially macros and then VBA code, and VS
It's one of the platforms that MSFT has to entice new developers.
<those are hardly a step forward from a developer's standpoint, but the end user is generally very excited about them. >
And that's a problem. Going back to Susan Harkins' article--which boiled down to 'I don't miss the bigots and I don't miss cleaning up after amateurs'--these new features are things that cause more bigotry and more messes.
Given the price tag, if MSFT is going to sell more Access licences, it has to be into the enterprise. The biggest barrier to increased sales is not the learning curve for the end-user. It's that anti-Access bigotry of most IT deparments. And these new 'features' do nothing to address that problem. What's needed is a method to ensure that users create quality apps that can be upgraded. That's been sorely needed for some time. Instead we've been getting tools (WebMatrix, LightSwitch, Access web apps and templates) that LET YOU CREATE AND APPLICATION IN NO TIME WITHOUT WRITING ANY CODE! It's a miracle. You can create a generic app that doesn't look all that good, that you don't understand, can't customize and does only what it's implementers thought you'd need it to do very quickly.
Yeah, this is good how?
Sigh.
I am depressed. I may have wasted a lot of effort to become a very good Access developer.
One question.
If you DON'T use Access or SQL Server Reporting Services, what do you use to print?
And don't say Crystal Reports!
Those last two have to do with SharePoint integration--which nobody looking at an app with any kind of growth curve thinks is a good idea.
50000 items to a lsit and no upgrade path are complete show stoppers for any serious app.
<but it's short sighted to presume that MSFT will always have the best interest of the developer at heart.>
A platform without developers is dead. Developers aren't the only thing a platform needs, by a long shot, but they are an essential ingredient.
<You have to learn the ins-and-outs of database design, form design, etc etc in order to utilize the full potential of Access. >
Absolutely. Which means that it's the intemediate step between Excel, with its formulas, initially macros and then VBA code, and VS
It's one of the platforms that MSFT has to entice new developers.
<those are hardly a step forward from a developer's standpoint, but the end user is generally very excited about them. >
And that's a problem. Going back to Susan Harkins' article--which boiled down to 'I don't miss the bigots and I don't miss cleaning up after amateurs'--these new features are things that cause more bigotry and more messes.
Given the price tag, if MSFT is going to sell more Access licences, it has to be into the enterprise. The biggest barrier to increased sales is not the learning curve for the end-user. It's that anti-Access bigotry of most IT deparments. And these new 'features' do nothing to address that problem. What's needed is a method to ensure that users create quality apps that can be upgraded. That's been sorely needed for some time. Instead we've been getting tools (WebMatrix, LightSwitch, Access web apps and templates) that LET YOU CREATE AND APPLICATION IN NO TIME WITHOUT WRITING ANY CODE! It's a miracle. You can create a generic app that doesn't look all that good, that you don't understand, can't customize and does only what it's implementers thought you'd need it to do very quickly.
Yeah, this is good how?
Sigh.
I am depressed. I may have wasted a lot of effort to become a very good Access developer.
One question.
If you DON'T use Access or SQL Server Reporting Services, what do you use to print?
And don't say Crystal Reports!
For something a little lighter, my aging brain is not able to find why a query I have developed on a table in the askers's mdb will not run. Although the query appears to populate, the error message appears after about 10 seconds, and the underlying datasheet view goes completely blank after about 30 seconds.
https://www.experts-exchange.com/questions/27398521/Build-Table-with-Functions.html?anchorAnswerId=36980334#a36980334
https://www.experts-exchange.com/questions/27398521/Build-Table-with-Functions.html?anchorAnswerId=36980334#a36980334
> If you DON'T use Access or SQL Server Reporting Services, what do you use to print?
But I _do_ use Reporting Services of Visual Studio. A little hard to get around when you are used to Access, but then - a wonderful tool at zero cost with direct output/export from the ReportViewer to Excel and PDF.
Study some samples from the workbench-project here:
Nortwind.net at CodePlex
/gustav
But I _do_ use Reporting Services of Visual Studio. A little hard to get around when you are used to Access, but then - a wonderful tool at zero cost with direct output/export from the ReportViewer to Excel and PDF.
Study some samples from the workbench-project here:
Nortwind.net at CodePlex
/gustav
@GRayL
Straight up SQL for what your OP wanted is well beyond me.
A parameter form, a table and VBA code was imminently doable.
Let me know what you think .
Straight up SQL for what your OP wanted is well beyond me.
A parameter form, a table and VBA code was imminently doable.
Let me know what you think .
"<Just look at the recent changes in Access (Ribbons, MVF's and Attachment fields) >
Those last two have to do with SharePoint integration--which nobody looking at an app with any kind of growth curve thinks is a good idea.
50000 items to a lsit and no upgrade path are complete show stoppers for any serious app."
I don't really think you're understanding my overall concept.
You think of Access as a development platform. The typical Access user does not - to them, it's no different than a Word Document, or an Excel spreadsheet, except that it is a LOT more difficult to work with. The goal of MSFT is to remove that difficulty. That does not include adding cool new VBA features, or the ability to work more closely with ActiveX controls, or anything else here. It includes making Access more like Excel, to put it bluntly, with an easier to use "customization" paradigm. That would not include VBA, of course, but instead it would include macros. If you've spent any time with the 2007 or 2010 macro designer, you'll find that to be quite obvious.
"<but it's short sighted to presume that MSFT will always have the best interest of the developer at heart.>
A platform without developers is dead. Developers aren't the only thing a platform needs, by a long shot, but they are an essential ingredient."
See my comment above. It's quite obvious to me that MSFT doesn't really view Access as a development platform, and as such isn't going to expend a great amount of energy on the developer side of things. That's not to say they'll completely drop the developer side. There is still an active team that works with those things, and they still depend on the devs to beat up Access and report back. But I'd hazard a guess that you'll find few developer-centric changes in Access 14, and a lot of new "cool" UI features!
"Given the price tag, if MSFT is going to sell more Access licences, it has to be into the enterprise. The biggest barrier to increased sales is not the learning curve for the end-user. It's that anti-Access bigotry of most IT deparments."
The biggest barrier is not IT "bigotry". In fact, I'd be willing to bet you that if a corporation finds value in the new features of Access, the IT department will find a way to support it (or they'll find a way to polish up their resumes). The biggest barrier to selling more licenses is the fact that Access is difficult to use for the typical end users, and therefore most corporate clients see little value in it. MSFT is banking on that, of course, and therefore the brunt of new features are user-centric, and not developer centric. Just look at the changes made between 2003 and 2007, and tell me which of those were focused around the developer ....
" And these new 'features' do nothing to address that problem. What's needed is a method to ensure that users create quality apps that can be upgraded. That's been sorely needed for some time. Instead we've been getting tools (WebMatrix, LightSwitch, Access web apps and templates) that LET YOU CREATE AND APPLICATION IN NO TIME WITHOUT WRITING ANY CODE! It's a miracle. You can create a generic app that doesn't look all that good, that you don't understand, can't customize and does only what it's implementers thought you'd need it to do very quickly."
But that was the original vision for Access - to create small, workgroup-sized apps that provided a solution for a specific business problem. We (i.e. the active Access developers) have pushed that envelope, and we've assumed that MSFT would follow us and provide for us the tools we needed. That didn't happen (and with good reason) and in my opinion it's not going to happen anytime in the future (see the changes made in Access 2010 - they were all user-centric). To me, MSFT has pretty much always said "If you want to build enterprise-level apps, then you need to move to an enterprise-level platform".
Those last two have to do with SharePoint integration--which nobody looking at an app with any kind of growth curve thinks is a good idea.
50000 items to a lsit and no upgrade path are complete show stoppers for any serious app."
I don't really think you're understanding my overall concept.
You think of Access as a development platform. The typical Access user does not - to them, it's no different than a Word Document, or an Excel spreadsheet, except that it is a LOT more difficult to work with. The goal of MSFT is to remove that difficulty. That does not include adding cool new VBA features, or the ability to work more closely with ActiveX controls, or anything else here. It includes making Access more like Excel, to put it bluntly, with an easier to use "customization" paradigm. That would not include VBA, of course, but instead it would include macros. If you've spent any time with the 2007 or 2010 macro designer, you'll find that to be quite obvious.
"<but it's short sighted to presume that MSFT will always have the best interest of the developer at heart.>
A platform without developers is dead. Developers aren't the only thing a platform needs, by a long shot, but they are an essential ingredient."
See my comment above. It's quite obvious to me that MSFT doesn't really view Access as a development platform, and as such isn't going to expend a great amount of energy on the developer side of things. That's not to say they'll completely drop the developer side. There is still an active team that works with those things, and they still depend on the devs to beat up Access and report back. But I'd hazard a guess that you'll find few developer-centric changes in Access 14, and a lot of new "cool" UI features!
"Given the price tag, if MSFT is going to sell more Access licences, it has to be into the enterprise. The biggest barrier to increased sales is not the learning curve for the end-user. It's that anti-Access bigotry of most IT deparments."
The biggest barrier is not IT "bigotry". In fact, I'd be willing to bet you that if a corporation finds value in the new features of Access, the IT department will find a way to support it (or they'll find a way to polish up their resumes). The biggest barrier to selling more licenses is the fact that Access is difficult to use for the typical end users, and therefore most corporate clients see little value in it. MSFT is banking on that, of course, and therefore the brunt of new features are user-centric, and not developer centric. Just look at the changes made between 2003 and 2007, and tell me which of those were focused around the developer ....
" And these new 'features' do nothing to address that problem. What's needed is a method to ensure that users create quality apps that can be upgraded. That's been sorely needed for some time. Instead we've been getting tools (WebMatrix, LightSwitch, Access web apps and templates) that LET YOU CREATE AND APPLICATION IN NO TIME WITHOUT WRITING ANY CODE! It's a miracle. You can create a generic app that doesn't look all that good, that you don't understand, can't customize and does only what it's implementers thought you'd need it to do very quickly."
But that was the original vision for Access - to create small, workgroup-sized apps that provided a solution for a specific business problem. We (i.e. the active Access developers) have pushed that envelope, and we've assumed that MSFT would follow us and provide for us the tools we needed. That didn't happen (and with good reason) and in my opinion it's not going to happen anytime in the future (see the changes made in Access 2010 - they were all user-centric). To me, MSFT has pretty much always said "If you want to build enterprise-level apps, then you need to move to an enterprise-level platform".
<I don't really think you're understanding my overall concept.>
I do understand it. I just don't think it's right.
ANYTHING can be a development platform.
That includes VBScript and command-line batch files
How good a development platform something is has many factors
That would include developer productivity, platform flexibility, and scalability.
Access is outstanding in two out of the three
<To me, MSFT has pretty much always said "If you want to build enterprise-level apps, then you need to move to an enterprise-level platform". >
They flat out said that out loud to me in person, during the Access 2010 pre-beta consultation
"Oh, you are building LOB applications. That's not what we had in mind." And that's verbatim from Dany Hoter and Clint Covington @MSFT
Hoter & Company are well aware of the bigotry. They even asked for feedback on what it would take to mitigate it. Nothing was ever delivered.
<the original vision for Access - to create small, workgroup-sized apps that provided a solution for a specific business problem.>
The consistent problem is that a well-designed database app doesn't stay a small workgroup-sized app.
You do your job right and it grows into a mission critical LOB app.
<"If you want to build enterprise-level apps, then you need to move to an enterprise-level platform". >
Most times you don't start out there--but you end up there!
And there still is no good way to upscale from Access on the front-end--that's the biggest problem.
<In fact, I'd be willing to bet you that if a corporation finds value in the new features of Access, the IT department will find a way to support it (or they'll find a way to polish up their resumes).>
I'd take you up on that bet, and I'd likely win it. Value is one thing. Risk is another.
It is the risk end that fuels the Access FUD.
"Bob built our mission critical deparmental app and now it's not working!"
"So, get Bob to fix it"
"He died yesterday!"
The risk is the thing that needs to be mitigated, and so far it hasn't been. And that's a shame.
I do understand it. I just don't think it's right.
ANYTHING can be a development platform.
That includes VBScript and command-line batch files
How good a development platform something is has many factors
That would include developer productivity, platform flexibility, and scalability.
Access is outstanding in two out of the three
<To me, MSFT has pretty much always said "If you want to build enterprise-level apps, then you need to move to an enterprise-level platform". >
They flat out said that out loud to me in person, during the Access 2010 pre-beta consultation
"Oh, you are building LOB applications. That's not what we had in mind." And that's verbatim from Dany Hoter and Clint Covington @MSFT
Hoter & Company are well aware of the bigotry. They even asked for feedback on what it would take to mitigate it. Nothing was ever delivered.
<the original vision for Access - to create small, workgroup-sized apps that provided a solution for a specific business problem.>
The consistent problem is that a well-designed database app doesn't stay a small workgroup-sized app.
You do your job right and it grows into a mission critical LOB app.
<"If you want to build enterprise-level apps, then you need to move to an enterprise-level platform". >
Most times you don't start out there--but you end up there!
And there still is no good way to upscale from Access on the front-end--that's the biggest problem.
<In fact, I'd be willing to bet you that if a corporation finds value in the new features of Access, the IT department will find a way to support it (or they'll find a way to polish up their resumes).>
I'd take you up on that bet, and I'd likely win it. Value is one thing. Risk is another.
It is the risk end that fuels the Access FUD.
"Bob built our mission critical deparmental app and now it's not working!"
"So, get Bob to fix it"
"He died yesterday!"
The risk is the thing that needs to be mitigated, and so far it hasn't been. And that's a shame.
And we've yet to hear from Joe (DatabaseMX).
If they would have come up with some way to extract the FE to a, decently, compilable source code and the back end to SQL Server -- I would have quickly grown to building full scale apps. ADP was a half measure -- but you could do so much client side, still, that it never quite worked.
I'm now Level III support of an app that has very little client side but presentation. I have become so familiar with how to break down a SQL Server sp, function, etc. that it is second nature.
If they further degrade the stepping stone for developers they will lose loyalty. Just about every good developer I know for any DB apps has spent at least a decent modicum of time in Access. Either as front-end, back-end, or both.
I'm now Level III support of an app that has very little client side but presentation. I have become so familiar with how to break down a SQL Server sp, function, etc. that it is second nature.
If they further degrade the stepping stone for developers they will lose loyalty. Just about every good developer I know for any DB apps has spent at least a decent modicum of time in Access. Either as front-end, back-end, or both.
"And we've yet to hear from Joe (DatabaseMX)."
Kinda waitin' to have the last word, lol.
mx
Kinda waitin' to have the last word, lol.
mx
Unless the rapture happens, there won't be a last word!
>>Unless the rapture happens...
Speaking of which...our favorite nut bag, Harold Camping, has set a new date for the rapture to Oct 21st. (for those of your that weren't taken a few months ago)
Speaking of which...our favorite nut bag, Harold Camping, has set a new date for the rapture to Oct 21st. (for those of your that weren't taken a few months ago)
So @mx has to post before midnight of the 21st. What time zone?
Harold Camping is laughing all the way to the bank. Something like a 140 Million Dollar empire ...
mx
mx
I think he's dead now
nope. still alive. and still wealthy.
Harold Camping ...what comes around goes around !
What is this chit-chat? I'm lost.
/gustav
/gustav
A north american joke. @GRayL said that @mx hadn't commented yet. @mx said he was waiting to get in the last word. Since this question has no answer, the only way for @mx to have the last word would be if the Christian end of the world, the rapture where everyone is bodily assumed into heaven, occurred. A preacher named Harold Camping has proclaimed that this has/will occur this year. The 'spiritual' one occurred in May. In October the rest of the saintly will be taken up...or not.
Oh, thanks. Let me guess: November will turn up as usual.
/gustav
/gustav
< Oct 21st>
I certainly hope not!
I'm planning to run a marathon on October 30th. Its been waaay too much training for something silly like the end of the world to get in the way...
I certainly hope not!
I'm planning to run a marathon on October 30th. Its been waaay too much training for something silly like the end of the world to get in the way...
==<I don't really think you're understanding my overall concept.>
I do understand it. I just don't think it's right.==
But it is. You consider Access to be a development platform. MSFT does not, and there is ample evidence of that (try to find Access in the "developer" section of your MSDN downloads). That is my entire point. I agree with your other assessments regarding what constitutes a development platform, and I too believe that Access is a very good platform. MSFT thinks of it as an Office app, like Word or Excel.
To summarize my overall concept: While we (the serious Access developers) consider Access to be a valuable development platform, MSFT believes Access to be a typical Office application that can be customized for specific business needs.
== <To me, MSFT has pretty much always said "If you want to build enterprise-level apps, then you need to move to an enterprise-level platform". >
They flat out said that out loud to me in person, during the Access 2010 pre-beta consultation
"Oh, you are building LOB applications. That's not what we had in mind." And that's verbatim from Dany Hoter and Clint Covington @MSFT
Hoter & Company are well aware of the bigotry. They even asked for feedback on what it would take to mitigate it. Nothing was ever delivered.==
I've never said the bigotry doesn't exist, simply that it's not the final deciding factor in whether to deploy Access throughout a company. See my comments re: value + risk below.
As I said earlier - if MSFT sees value in adding enterprise-level features to Access, then you can be sure that would happen. Entperprise level features are far more ensconced in the developer camp than in the user camp. The average user couldn't care less whether Access supports enterprise-level development. They just want to get their work done (and their company wants that as well).
==<the original vision for Access - to create small, workgroup-sized apps that provided a solution for a specific business problem.>
The consistent problem is that a well-designed database app doesn't stay a small workgroup-sized app.
You do your job right and it grows into a mission critical LOB app.==
True, but I don't see what that has to do with MSFT's intended use for Access. Just beacuse YOU (and me, and every other serious Access developer) know that our apps will outgrow the workgroup doesn't mean that it's MSFT's job to provide Access with features that will make it easier to expand. It'd be nice if it did, but - again - that is more of a developer feature, and less of a user feature. As they have apparently told you, if you're building enterprise or LOB apps, the move to a different platform.
==And there still is no good way to upscale from Access on the front-end--that's the biggest problem.==
Having spent quite a bit of time in VB.NET, I can't imagine what it would take to move an Access form/subform to the VB.NET environment. There is no such thing as a Subform in .NET, so it would be nearly impossible to do so reliably. They could probably do a decent job at moving code over, but that'd be about it (and even then I'd HATE to support an app that was automagically upsized to .NET).
Also, given that .NET has been out for a long while, if there were a market for this, it would seem that some of the 3rd party companies would have made inroads into this sort of utility. There were a few that converted VB6 to .NET, but they floundered and failed long ago, simply because the conversion required as much cleanup work as it would have taken to just rewrite it in .NET. The same would almost certainly hold true for Access, and it would almost certainly be worse.
==<In fact, I'd be willing to bet you that if a corporation finds value in the new features of Access, the IT department will find a way to support it (or they'll find a way to polish up their resumes).>
I'd take you up on that bet, and I'd likely win it. Value is one thing. Risk is another.
It is the risk end that fuels the Access FUD.
"Bob built our mission critical deparmental app and now it's not working!"
"So, get Bob to fix it"
"He died yesterday!"==
I seriously doubt you'd win, but I guess we'll never be able to find that out! Value and risk go hand in hand (Business 101), so I didn't really feel the need to go into detail about that.
My comment still stands - if the company finds value in deploying Access to the enterprise, then it will happen, regardless of the push back from IT. Of course, when management is deciding whether to do this, they would naturally ask for risk assessments, and this is when IT would come into play. At that point if the company finds that the risk is too great - and IT would have a very large hand in that, of course - then this would diminish the VALUE of that deployment, and would (perhaps) make it unfeasible. That's a decision that is made based on many, many factors - and not just whether the IT dept wants to deploy and support Access.
There are many very large corporations and government entities that have deployed Access in their environment, and I can pretty much bet that when these decision were being made there was pushback from the IT departments. The deployments still happened, because management decided that the value was worth more than the risk. That "value" is the shiny ball that MSFT is chasing, and I believe they fully understand that no matter what they do on the developer or deployment side of things, the average IT worker is NOT going to take a liking to Access. Therefore, they work very, very hard on the shiny trinkets that the average data user would like to see (i.e. the UI stuff) - and that's why we see so many UI additions, and very, very few developer additions.
And the critical deparment app could have been written in VB.NET, or C#, or ColdFusion, and the company would still be in the same boat if Bob gets hit by a bus :)
"The risk is the thing that needs to be mitigated, and so far it hasn't been. And that's a sham"
The way I see it is this: MSFT already has a rapid development platform which can be used for enterprise level applications (VB.NET). What would be the VALUE in adding these same features to Access? Would this result in a net profit for MSFT? I'm not sure, since I have no idea what the cost would be to implement those features, but my guess is a resounding NO - otherwise, this would have long since been done since we've been bitching about these same things since Access 2.0 :).
I do understand it. I just don't think it's right.==
But it is. You consider Access to be a development platform. MSFT does not, and there is ample evidence of that (try to find Access in the "developer" section of your MSDN downloads). That is my entire point. I agree with your other assessments regarding what constitutes a development platform, and I too believe that Access is a very good platform. MSFT thinks of it as an Office app, like Word or Excel.
To summarize my overall concept: While we (the serious Access developers) consider Access to be a valuable development platform, MSFT believes Access to be a typical Office application that can be customized for specific business needs.
== <To me, MSFT has pretty much always said "If you want to build enterprise-level apps, then you need to move to an enterprise-level platform". >
They flat out said that out loud to me in person, during the Access 2010 pre-beta consultation
"Oh, you are building LOB applications. That's not what we had in mind." And that's verbatim from Dany Hoter and Clint Covington @MSFT
Hoter & Company are well aware of the bigotry. They even asked for feedback on what it would take to mitigate it. Nothing was ever delivered.==
I've never said the bigotry doesn't exist, simply that it's not the final deciding factor in whether to deploy Access throughout a company. See my comments re: value + risk below.
As I said earlier - if MSFT sees value in adding enterprise-level features to Access, then you can be sure that would happen. Entperprise level features are far more ensconced in the developer camp than in the user camp. The average user couldn't care less whether Access supports enterprise-level development. They just want to get their work done (and their company wants that as well).
==<the original vision for Access - to create small, workgroup-sized apps that provided a solution for a specific business problem.>
The consistent problem is that a well-designed database app doesn't stay a small workgroup-sized app.
You do your job right and it grows into a mission critical LOB app.==
True, but I don't see what that has to do with MSFT's intended use for Access. Just beacuse YOU (and me, and every other serious Access developer) know that our apps will outgrow the workgroup doesn't mean that it's MSFT's job to provide Access with features that will make it easier to expand. It'd be nice if it did, but - again - that is more of a developer feature, and less of a user feature. As they have apparently told you, if you're building enterprise or LOB apps, the move to a different platform.
==And there still is no good way to upscale from Access on the front-end--that's the biggest problem.==
Having spent quite a bit of time in VB.NET, I can't imagine what it would take to move an Access form/subform to the VB.NET environment. There is no such thing as a Subform in .NET, so it would be nearly impossible to do so reliably. They could probably do a decent job at moving code over, but that'd be about it (and even then I'd HATE to support an app that was automagically upsized to .NET).
Also, given that .NET has been out for a long while, if there were a market for this, it would seem that some of the 3rd party companies would have made inroads into this sort of utility. There were a few that converted VB6 to .NET, but they floundered and failed long ago, simply because the conversion required as much cleanup work as it would have taken to just rewrite it in .NET. The same would almost certainly hold true for Access, and it would almost certainly be worse.
==<In fact, I'd be willing to bet you that if a corporation finds value in the new features of Access, the IT department will find a way to support it (or they'll find a way to polish up their resumes).>
I'd take you up on that bet, and I'd likely win it. Value is one thing. Risk is another.
It is the risk end that fuels the Access FUD.
"Bob built our mission critical deparmental app and now it's not working!"
"So, get Bob to fix it"
"He died yesterday!"==
I seriously doubt you'd win, but I guess we'll never be able to find that out! Value and risk go hand in hand (Business 101), so I didn't really feel the need to go into detail about that.
My comment still stands - if the company finds value in deploying Access to the enterprise, then it will happen, regardless of the push back from IT. Of course, when management is deciding whether to do this, they would naturally ask for risk assessments, and this is when IT would come into play. At that point if the company finds that the risk is too great - and IT would have a very large hand in that, of course - then this would diminish the VALUE of that deployment, and would (perhaps) make it unfeasible. That's a decision that is made based on many, many factors - and not just whether the IT dept wants to deploy and support Access.
There are many very large corporations and government entities that have deployed Access in their environment, and I can pretty much bet that when these decision were being made there was pushback from the IT departments. The deployments still happened, because management decided that the value was worth more than the risk. That "value" is the shiny ball that MSFT is chasing, and I believe they fully understand that no matter what they do on the developer or deployment side of things, the average IT worker is NOT going to take a liking to Access. Therefore, they work very, very hard on the shiny trinkets that the average data user would like to see (i.e. the UI stuff) - and that's why we see so many UI additions, and very, very few developer additions.
And the critical deparment app could have been written in VB.NET, or C#, or ColdFusion, and the company would still be in the same boat if Bob gets hit by a bus :)
"The risk is the thing that needs to be mitigated, and so far it hasn't been. And that's a sham"
The way I see it is this: MSFT already has a rapid development platform which can be used for enterprise level applications (VB.NET). What would be the VALUE in adding these same features to Access? Would this result in a net profit for MSFT? I'm not sure, since I have no idea what the cost would be to implement those features, but my guess is a resounding NO - otherwise, this would have long since been done since we've been bitching about these same things since Access 2.0 :).
ASKER
I have to say, I'm with Scott all the way on this one. MSFT simply doesn't consider Access a development platform and it never has.
I see a re-focus on the end user with new features and developers getting pushed off to Lightswitch and .Net/VS.
Jim.
== If you DON'T use Access or SQL Server Reporting Services, what do you use to print?
And don't say Crystal Reports! ==
Hate to say it .... but I use CR and think it's a great platform, and if you're working outside of Access then it is a very viable reporting engine. I've used it within Access (corporate client needed to view CR reports in an access app, for some reason) and that was relatively easy to manage as well with the older CR ActiveX control. However, I've personally not seen an instance where I felt the need to move away from the Access reporting platform to CR (for an Access application anyway).
It is very difficult to learn and requires quite an investment of time and effort. It's used extensively in the business world so learning CR can certainly get your foot in the door with some clients.
I did migrate one client away from an Access reporting utlity to CR. They had custom built their own Access centralized reporting utility (and had not done a very good job), and they were having lots of troubles deploying new reports, changes etc etc. They already have CR on their machines, so we just rewrote the reports in CR (there were only about a dozen) and dropped the .rpt files to a central location, and copied those .rpt files to the local machine whenever the Access FE started. worked very well, and the client was very satisfied, and they could easily make changes to the .rpt files as needed and "deploy" them easily. This probably wouldn't be a good fit if you had a LOT of reports, of course.
I've also used ActiveReports, which is a very nice platform.
And don't say Crystal Reports! ==
Hate to say it .... but I use CR and think it's a great platform, and if you're working outside of Access then it is a very viable reporting engine. I've used it within Access (corporate client needed to view CR reports in an access app, for some reason) and that was relatively easy to manage as well with the older CR ActiveX control. However, I've personally not seen an instance where I felt the need to move away from the Access reporting platform to CR (for an Access application anyway).
It is very difficult to learn and requires quite an investment of time and effort. It's used extensively in the business world so learning CR can certainly get your foot in the door with some clients.
I did migrate one client away from an Access reporting utlity to CR. They had custom built their own Access centralized reporting utility (and had not done a very good job), and they were having lots of troubles deploying new reports, changes etc etc. They already have CR on their machines, so we just rewrote the reports in CR (there were only about a dozen) and dropped the .rpt files to a central location, and copied those .rpt files to the local machine whenever the Access FE started. worked very well, and the client was very satisfied, and they could easily make changes to the .rpt files as needed and "deploy" them easily. This probably wouldn't be a good fit if you had a LOT of reports, of course.
I've also used ActiveReports, which is a very nice platform.
I rarely use Access Reports, even in Access applications.
Our clients usually want data reported in Excel, which offers a lot more flexibility for the person receiving the report.
I second CR as a great tool for reporting as well.
<< I see a re-focus on the end user with new features and developers getting pushed off to Lightswitch and .Net/VS. >>
The writing is definitely on the wall for this, and from a developer's perspective I think now is a great time to branch out and dive into learning new skills.
Our clients usually want data reported in Excel, which offers a lot more flexibility for the person receiving the report.
I second CR as a great tool for reporting as well.
<< I see a re-focus on the end user with new features and developers getting pushed off to Lightswitch and .Net/VS. >>
The writing is definitely on the wall for this, and from a developer's perspective I think now is a great time to branch out and dive into learning new skills.
Access for the win (yesterday). I attended a meeting with my department-level clients to discuss the new EPIC software that is being 'integrated' into the hospital's IT system. EPIC is comprehensive and will replace all the core systems and as many of the peripheral systems as it can. Once the EPIC folks understood (the doctor had to do a demo of my app) the nature of the problem, our 'integration' was pushed back with their realization that they would have to recreate all my work if they wanted to functionally replace the Access database apps that these folks use.
"The writing is definitely on the wall for this, and from a developer's perspective I think now is a great time to branch out and dive into learning new skills"
+1
+1
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Jim,
You cheated.
Now how will @mx have the last word?
You cheated.
Now how will @mx have the last word?
06:00:00
? cdate(-0.25)
06:00:00
This agrees with what aikimark and gustav were saying in the previous thread. Something one has to be aware of when dealing with dates prior to 1899-12-30 00:00:00
BTW:
? datevalue(#01:00:00#)
00:00:00
Kind of a surprise. I seems that there is no way one can get Access 2003+ to create a date as simply 1899-12-30. It seemed to me Access 2000 would, but I no longer have it available to test. Thanks again everyone for your insights.