The small company I work for has installed codebases in Access 2003 and VS2005/.NET 2.0 (C#, I'm the C# guy, we do winforms and ASP.NET), both of which talk to SQL 2000. My question for anon is where should the company put their eggs going forward?

The death of access has been predicted for years but doesn't seem to be happening. On the other hand I'm not real sanguine about the future of .NET either. Microsoft gives us 10 years in each development paradigm--we had 10 years in DOS, 10 years in COM and now we're at about that point with .NET.

Wat do? Leave both sets of codebases alone and continue on with both access and .NET until the market isn't in such a state of flux? Migrate access to something else? Migrate .NET elsewhere? Wait to see what happens with winRT and the enterprise?

Business decisions are most often motivated by value added to products and not upgrades for upgrade's sake, (of course).

I'd work on upgrading from SQL 2000 first. A lot has happened to that product since then, and it shouldn't be too much of a development effort to upgrade.

I'd encourage Entity Framework and WCF services research in general.

rule #1 if it's not broke then do not try to fix it.

if a given thing is having problems then evaluate what needs to be fixed.

there is a lot about access that is really great, other bits not so much....

.Net - IMHO it's going to be around for a good long time ....

I can't provide any specific suggestions without knowing what you are doing, but I personally like PostgreSQL and MySQL for databases.

13 minutes ago, Bass wrote

I would look at building solutions on top of non-proprietary technology. This is so that your company won't be having to predict Microsoft's next strategy (like you are currently doing). I can't provide any specific suggestions without knowing what you are doing, but I personally like PostgreSQL and MySQL for databases.

That just means you're predicting the Open Source communities' next strategy though, which given there is rarely any sort of roadmap or consistency, can be a far harder thing to predict. And the recent debacle over DNT and Apache only goes to prove you aren't even free from the whims of corporate paymasters when you go with a FOSS solution either, even if it's a long standing project.

The only problem I see is that mdb files don't play nicely with .NET nowadays. Switching to a different solution (such as SQL Server Compact, for instance) can be a life saver in some case.

9 hours ago, Blue Ink wrote

@figuerres: +1

The only problem I see is that mdb files don't play nicely with .NET nowadays. Switching to a different solution (such as SQL Server Compact, for instance) can be a life saver in some case.

the OP also mentioned SQL 2000 and i would have them look at at the least upgrading to SQL 2008 or 2012 if they want to stay with the Microsoft servers.....

http://www.zdnet.com/as-the-microsoft-developer-world-turns-guidance-for-the-perplexed-7000004423/

though I disagree with Telerik on WPF and Silverlight and don't intend doing anything with them (see some of the comments on WPF). Winforms and ASP.NET seem to be good bets going forward, and I like the comment above on gradually edging away from Access.

Unless you find a job with a better company =)

Can't get another job, brosef. At 53 I'm too old. I'm at the top of my game and can't get on anywhere else. Years in the field = more expensive to hire. 

You'd better consider WPF, my .02

30 minutes ago, boogop wrote

Sure I can, SQL 2000 is fine as long as you can work around some of its limitations. Pull data out, use it, stick it back.

Can't get another job, brosef. At 53 I'm too old. I'm at the top of my game and can't get on anywhere else. Years in the field = more expensive to hire. 

Then I am an extreme exception to your rule at 51, old man. I can't shake headhunters off fast enough.

2 minutes ago, JohnAskew wrote

Winforms is not a good choice for the future. It is stuck in Win32 API, so it is obsolete imho.

A) WinForms is a set of APIs that could be repurposed if the Win32 API changed - see Mono for an example of WinForms that sits on top of fopens etc instead of CreateFiles.

B) Win32 cannot, and will not ever die - at least not in my lifetime. The fact that a hundred billion world-critical applications run on it effectively guarantees Win32's future.

C) All of the alternatives you might think have killed Win32, are actually Win32 in disguise. WinRT and WPF and Silverlight and even the HTML rendering in Windows all ultimately boil down to Win32.

So I would, in fact, argue the exact opposite. I'd program in Win32 in preference to new kids on the block like WinRT. WinRT is new, there aren't many developers and those key facts make it easy for Microsoft to mess you around, like they've done with Silverlight and WPF.

Microsoft can't mess around with Win32, so as long as tablets aren't important to you, I'd keep using that.

Likewise, man. Headhunters see the resume and burn up my phone line. Contract work I could get, but permanent work...they seem to see the hiring cost and pass.

c) that's due to the OS, isn't it? Those technologies have no hard dependencies on Win32 API, unless I am mistaken.

b) I would not stake my business on that, personally, I believe hard dependencies on OS dlls are obsolete technology, philosophically, and I'd seek remedy if possible -- re: WPF, etc.

a) XAML beats the dog snot out of the UI in Winforms, it is a much better programming model.

My perspective is optimistic. Changes to WPF, Silverlight, WinRT are responses to community demand and technological best practices. Every single iteration of deliverables are welcome here. I will state that most of my own pain working around these type changes were due to poor code designs on my part and not from API modifications. That's my experience with .NET and it is not the same experience I had with other languages.

Ah, you have dirt under the rug... to wit: "as long as tablets aren't important"... ah-hem. Obsolete!

I do appreciate your perspective, but I'm not sharing it.

17 minutes ago, JohnAskew wrote

c) that's due to the OS, isn't it? Those technologies have no hard dependencies on Win32 API, unless I am mistaken.

b) I would not stake my business on that, personally, I believe hard dependencies on OS dlls are obsolete technology, philosophically, and I'd seek remedy if possible -- re: WPF, etc.

It seems like the bulk of RT is tons of metadata glue that wraps around all of the APIs that are needed to provide the RT API set. Whether they be native or managed, the developer doesn't need to know or care. Microsoft can make whatever changes they need to the underlying APIs, up to and including getting rid of Win32, and RT applications wouldn't need to know about it.

a) XAML beats the dog snot out of the UI in Winforms, it is a much better programming model.

QFT

My perspective is optimistic. Changes to WPF, Silverlight, WinRT are responses to community demand and technological best practices. Every single iteration of deliverables are welcome here. I will state that most of my own pain working around these type changes were due to poor code designs on my part and not from API modifications. That's my experience with .NET and it is not the same experience I had with other languages.

I've been optimistic about this process too. I don't see the death of WPF, Silverlight, or any technologies. What I'm seeing is that each iteration has brought them all closer together, and they are finally merging into one cohesive stack. The process is a bit messy, but I don't see any reason somebody would say it isn't necessary.

2 hours ago, evildictait​or wrote

*snip*

A) WinForms is a set of APIs that could be repurposed if the Win32 API changed - see Mono for an example of WinForms that sits on top of fopens etc instead of CreateFiles.

It really can't, or at least not easily and reliably without mimicking a lot of Win32 too. Many of the assumptions in WinForms are inherent to Win32 and the underlying design tend to leak through a lot. Couple that with the fact Microsoft have already declared it dead and I'd try to steer away from it.

Well that, coupled with the fact it's horrendously buggy in places, mostly because the controls are very light wrappers around the Win32 provided controls but with different (and often incompatible) semantics. It's enormously easy, for example, to create a data-bound combo box that corrupts data simply due to the order properties are set on it (and it's really not obvious what the correct way is).

By contrast, WPF keeps itself well clear of Win32 and the fact it happens to be implemented on top of it is largely irrelevant.