September 8, 2010 at 7:49 am
understanding it removes the cross platform capabilities that some developers desire but why MS doesn't just build Express into Windows I don't know. They install it with other components of theirs (I believe it was the Business contact manager of a few years back.) This would alleviate the issues of having multiple db instances on a machine however add other potential issues. But for the purpose of lightweight small dbs I think it has a good place.
Other issue is management. It needs to be as automated as possible as if it is embedded it won't be looked at either.
September 8, 2010 at 8:56 am
You think that is frustrating. I am still waiting for them to put a WHERE clause on a TRUNCATE statement.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
September 8, 2010 at 9:04 am
Embedded Express might make sense (with automated maintenance), but it would be single instance, with multiple databases. Typically people are installing separate instances of Express for applications, which is fine.
September 8, 2010 at 9:27 am
If one is distributing something like a shareware application, where there are potentially thousands of installs with a local instance of the database and you can't field even a small percentage of the support calls, then perhaps SQL Server Compact Edition would be a better choice than Express Edition. Similar to MS Access, installing the SSCE engine and backing up the database is simply a matter of copying files.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 8, 2010 at 8:55 pm
Wow, he looks quite frustrated!
September 8, 2010 at 9:01 pm
jcrawf02 (9/8/2010)I saw that one, I meant a coherent request like yours: 😉
I'd like to see Express not only have a very simple setup that works across multiple versions of Visual Studio, but also basic maintenance plans built in that allow full and log backups (if needed), along with index rebuilds with a simple switch set as a part of setup. A few registry keys or XML config changes could set paths or frequencies.
That's pure GOLD! 😀
September 9, 2010 at 7:22 am
TravisDBA (9/8/2010)
You think that is frustrating. I am still waiting for them to put a WHERE clause on a TRUNCATE statement.:-D
What makes the TRUNCATE statement more efficient is that it deallocates entire pages instead of individual rows, so a truncate with a WHERE clause would revert back to effectively becomming a DELETE. If you have a large table and need to quickly truncate a segment of data, then you could partition the table and drop individual partitions.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 9, 2010 at 7:42 am
Eric Russell 13013 (9/9/2010)
TravisDBA (9/8/2010)
You think that is frustrating. I am still waiting for them to put a WHERE clause on a TRUNCATE statement.:-DWhat makes the TRUNCATE statement more efficient is that it deallocates entire pages instead of individual rows, so a truncate with a WHERE clause would revert back to effectively becomming a DELETE. If you have a large table and need to quickly truncate a segment of data, then you could partition the table and drop individual partitions.
I was being facetious. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
September 9, 2010 at 10:08 am
Rod Weir (9/8/2010)
Not sure what the fuss is about. I've been installing just about every version of SQL from v6.5. Not just installing, but remote deployment and packaging with software installations.The latest SQL Server 2008 R2 is the best installer package I've used to date.
SQL Server is enterprise software, and considering the power it has, the installer is pretty good. Not perfect, but doable with the right amount of research 😉
Rod
I tend to agree with this. For the most part it seems that SQL server is fairly easy to install and has gotten better over time.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
September 9, 2010 at 3:53 pm
I am a Developer and NOT a DBA and never considered myself one, though I have done such things from time to time.
I have found using SQL Express and SQL Standard very easy to deploy and configure over the last 8 or 9 years, even when using non-Microsoft development tools.
But I owe most of that to SQL Central, I have been a reader of the newsletter and forums for some time and have picked up a great deal of knowledge from you "Pros". Thanks so much guys & gals.
For Small local apps (as opposed to Client Server w/ shared data) I usually use Access "Tables" since I don't need to have any user configuration involved. I still use "UDL"s instead of hard coding so they can be connected to SQL in the future if needed.
September 9, 2010 at 4:56 pm
When it comes to installing SQL Server Standard and Enterprise edition for a corporate IT groups, these installations are typically performed by a DBA who is familiar with the options presented and not really in a rush to get it done.
For local dev installations of SQL Server Express or Developer edition, like when you're installing Visual Studio, it's pretty straightforward. Stuff like choosing the location of the data files or setting up maintenace plans just doesn't matter. It's always been a no brainer.
For distrubuted installs of SQL Server, like something bundled with a shareware application or a corporate app installed on field representative laptops, you may want to just use SQL Server Express edition. Installing the database engine and backing up the database is just a matter of copying files. There is no windows service to manage or go haywire, and the data requirements for those type apps are usually lightweight anyhow.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 21, 2010 at 11:50 am
blandry (9/8/2010)
...and we call this progress. For me, looking over my decades in the business, its two steps forward, a hundred backwards as we layer complexity where simplicity would have done nicely.
When I started programming "back when", I could ask a user to input a number with an extremely simple command in the languages I programmed in.
1 language, 1 simple command.
Results: User could not proceed until they entered a valid number or left the field blank. No extra code required.
Now, to write a web app with the same "feature", it requires three languages for the same data entry screen. HTML, JavaScript or Regular Expressions, and C# or VB just to be safe, if the user turned off javascript.
That's not just backwards, it's bass-ackwards.
September 21, 2010 at 12:06 pm
david_wendelken (9/21/2010)
blandry (9/8/2010)
...and we call this progress. For me, looking over my decades in the business, its two steps forward, a hundred backwards as we layer complexity where simplicity would have done nicely.When I started programming "back when", I could ask a user to input a number with an extremely simple command in the languages I programmed in.
1 language, 1 simple command.
Results: User could not proceed until they entered a valid number or left the field blank. No extra code required.
Now, to write a web app with the same "feature", it requires three languages for the same data entry screen. HTML, JavaScript or Regular Expressions, and C# or VB just to be safe, if the user turned off javascript.
That's not just backwards, it's bass-ackwards.
But, security right aside, they can do it from anywhere using just a browser, whereas your previous application probably had to be installed on and run from their machine?
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
November 15, 2012 at 2:54 am
jcrawf02 (9/21/2010)
david_wendelken (9/21/2010)
blandry (9/8/2010)
...and we call this progress. For me, looking over my decades in the business, its two steps forward, a hundred backwards as we layer complexity where simplicity would have done nicely.When I started programming "back when", I could ask a user to input a number with an extremely simple command in the languages I programmed in.
1 language, 1 simple command.
Results: User could not proceed until they entered a valid number or left the field blank. No extra code required.
Now, to write a web app with the same "feature", it requires three languages for the same data entry screen. HTML, JavaScript or Regular Expressions, and C# or VB just to be safe, if the user turned off javascript.
That's not just backwards, it's bass-ackwards.
But, security right aside, they can do it from anywhere using just a browser, whereas your previous application probably had to be installed on and run from their machine?
Exactly. Just because things may have got a little (lot?) more complex for developers, let's not pretend software development as a whole has gone backwards over the last few decades. There have been some false steps I'm sure but the end products are clearly meeting some kind of real demand for end users.
November 15, 2012 at 2:58 am
To get back to the original topic...
From my experience of working in a small (3-man) development/ IT team, easier access to the cut-down versions of SQL Server should hopefully mean less MS Access. Which I think we can all agree is a good thing... it has its uses but the minute you have to scale it for data volumes/ multi-user access you run into problems.
I'll leave it there because that's a whole other debate I'm sure we don't want to get into 😉
Viewing 15 posts - 16 through 30 (of 41 total)
You must be logged in to reply to this topic. Login to reply