[OT] Great SSMS add in
Hi folks, A friend of mine wrote this *free *add-in for SSMS. It's a great search tool for finding and manipulating tables, stored procs, functions and views. http://sql-hunting-dog.com/ I love it. Of course, YMMV. Cheers DB
Re: [OT] Great SSMS add in
Thanks. Normally I just use the Info schema but this is way better :) On 4 June 2013 13:55, David Burstin david.burs...@gmail.com wrote: Hi folks, A friend of mine wrote this *free *add-in for SSMS. It's a great search tool for finding and manipulating tables, stored procs, functions and views. http://sql-hunting-dog.com/ I love it. Of course, YMMV. Cheers DB -- regards, Preet, Overlooking the Ocean, Auckland
If-else vs switch - declaring inner variables (a philosophical question)
Hi folks,
I was wondering if someone could explain the logic of the following in c#:
Using If-Else:
if (x == 7)
{
string foo = a;
}
else
{
string foo = b; // No problem declaring the string here
}
Using Switch:
switch (x)
{
case 7:
string foo = a;
break;
default:
string foo = b; // Compiler not happy because foo
already declared within the switch scope
break;
}
I understand that the scope for the second example is the entire switch
statement, but why does that need to be the case (pardon the pun)? Is it
just because of the ability to fall through from one case statement to the
next (by omitting the break)?
Just as a comparison, the compiler has no problem with the following in VB:
Select Case x
Case 7
Dim foo As String = a
Case Else
Dim foo As String = b
End Select
Lightweight database
Folks, an app has just grown with a new feature that needs to store of users, jobs and reports and the joins between them, If I was using SQLite it would be 3 tables with joins. However, rather than use SQLite this time I'd like to consider an alternative that's even more lightweight to setup and use. The app does not currently use any database technology and the guys managing the project are actually scared of them. Can anyone recommend an in-process database (not necessarily relational!) that is has a friendly managed API, small footprint, not too complicated and is easy to get going? I know this is a lot to ask, but there may be some NoSQL options around that I'm not aware of. The most important issues for me are: (1) *Minimal dependencies* (2) *Simple managed API*. I'm running a few web searches now for such things, and I can see Redis, Mongo, Couch, Raven, db4o, Cassandra, Eloquera, Lucene, and the list goes on and on. There are too many choices and it would take many days of hard slog to work out which one would be suitable. So perhaps someone has already been through this process?! I've been tempted many times over the last 10 years to write a pure managed single-file database with indexes, and nothing much else (no transactions, no client-server, no schemas, etc). However, I decided to leave it to the experts, and it looks like there are too many of them, and they all over-engineer their works. Cheers, Greg K
Re: Lightweight database
Not done this myself recently but what about an MDB file? Should '.net'/Ado/OLEDB/ODBC out of the box and I think the licensing is that if you have developer edition of office then you can distribute the runtime for free (but I could be wrong). Preet On 4 June 2013 14:24, Greg Keogh g...@mira.net wrote: Folks, an app has just grown with a new feature that needs to store of users, jobs and reports and the joins between them, If I was using SQLite it would be 3 tables with joins. However, rather than use SQLite this time I'd like to consider an alternative that's even more lightweight to setup and use. The app does not currently use any database technology and the guys managing the project are actually scared of them. Can anyone recommend an in-process database (not necessarily relational!) that is has a friendly managed API, small footprint, not too complicated and is easy to get going? I know this is a lot to ask, but there may be some NoSQL options around that I'm not aware of. The most important issues for me are: (1) *Minimal dependencies* (2) *Simple managed API*. I'm running a few web searches now for such things, and I can see Redis, Mongo, Couch, Raven, db4o, Cassandra, Eloquera, Lucene, and the list goes on and on. There are too many choices and it would take many days of hard slog to work out which one would be suitable. So perhaps someone has already been through this process?! I've been tempted many times over the last 10 years to write a pure managed single-file database with indexes, and nothing much else (no transactions, no client-server, no schemas, etc). However, I decided to leave it to the experts, and it looks like there are too many of them, and they all over-engineer their works. Cheers, Greg K -- regards, Preet, Overlooking the Ocean, Auckland
Re: If-else vs switch - declaring inner variables (a philosophical question)
David,
Try putting braces in:
switch (x)
{
case 7:
{
string foo = a;
break;
}
default:
{
string foo = b; // Compiler not happy because foo
already declared within the switch scope
break;
}
}
David
If we can hit that bullseye, the rest of the dominoes
will fall like a house of cards... checkmate!
-Zapp Brannigan, Futurama
On 4 June 2013 12:15, David Burstin david.burs...@gmail.com wrote:
Hi folks,
I was wondering if someone could explain the logic of the following in c#:
Using If-Else:
if (x == 7)
{
string foo = a;
}
else
{
string foo = b; // No problem declaring the string here
}
Using Switch:
switch (x)
{
case 7:
string foo = a;
break;
default:
string foo = b; // Compiler not happy because foo
already declared within the switch scope
break;
}
I understand that the scope for the second example is the entire switch
statement, but why does that need to be the case (pardon the pun)? Is it
just because of the ability to fall through from one case statement to the
next (by omitting the break)?
Just as a comparison, the compiler has no problem with the following in VB:
Select Case x
Case 7
Dim foo As String = a
Case Else
Dim foo As String = b
End Select
Re: Lightweight database
Greg, You could try just serialising to xml files. Of course, no transactions, not really much in the way of relationships. But it's very simple. It kind of depends on the situation. I recently had to convert an app that was using sqlce to using xml files because of reliability issues on the devices in question. It solved a lot of problem and mad the code simpler. David If we can hit that bullseye, the rest of the dominoes will fall like a house of cards... checkmate! -Zapp Brannigan, Futurama On 4 June 2013 12:24, Greg Keogh g...@mira.net wrote: Folks, an app has just grown with a new feature that needs to store of users, jobs and reports and the joins between them, If I was using SQLite it would be 3 tables with joins. However, rather than use SQLite this time I'd like to consider an alternative that's even more lightweight to setup and use. The app does not currently use any database technology and the guys managing the project are actually scared of them. Can anyone recommend an in-process database (not necessarily relational!) that is has a friendly managed API, small footprint, not too complicated and is easy to get going? I know this is a lot to ask, but there may be some NoSQL options around that I'm not aware of. The most important issues for me are: (1) *Minimal dependencies* (2) *Simple managed API*. I'm running a few web searches now for such things, and I can see Redis, Mongo, Couch, Raven, db4o, Cassandra, Eloquera, Lucene, and the list goes on and on. There are too many choices and it would take many days of hard slog to work out which one would be suitable. So perhaps someone has already been through this process?! I've been tempted many times over the last 10 years to write a pure managed single-file database with indexes, and nothing much else (no transactions, no client-server, no schemas, etc). However, I decided to leave it to the experts, and it looks like there are too many of them, and they all over-engineer their works. Cheers, Greg K
Re: If-else vs switch - declaring inner variables (a philosophical question)
Ok. Brackets will create a closed inner scope. But I am ruminating on the
intricacies of switch vs if-else from a language design point of view. If,
instead of adding brackets to the switch, I remove them from the if-else
and use 2 different variables it is now the if-else that doesn't compile:
if (x == 7)
string foo = a; // Invalid embedded statement
else
string bar = b; // Invalid embedded statement
switch (x)
{
case 7:
string foo = a; // No problems
break;
default:
string bar = b; // No problems
break;
}
As I said, it's a philosophical question - maybe better suited for a Friday.
On 4 June 2013 13:09, David Richards ausdot...@davidsuniverse.com wrote:
David,
Try putting braces in:
switch (x)
{
case 7:
{
string foo = a;
break;
}
default:
{
string foo = b; // Compiler not happy because foo
already declared within the switch scope
break;
}
}
David
If we can hit that bullseye, the rest of the dominoes
will fall like a house of cards... checkmate!
-Zapp Brannigan, Futurama
On 4 June 2013 12:15, David Burstin david.burs...@gmail.com wrote:
Hi folks,
I was wondering if someone could explain the logic of the following in c#:
Using If-Else:
if (x == 7)
{
string foo = a;
}
else
{
string foo = b; // No problem declaring the string
here
}
Using Switch:
switch (x)
{
case 7:
string foo = a;
break;
default:
string foo = b; // Compiler not happy because foo
already declared within the switch scope
break;
}
I understand that the scope for the second example is the entire switch
statement, but why does that need to be the case (pardon the pun)? Is it
just because of the ability to fall through from one case statement to the
next (by omitting the break)?
Just as a comparison, the compiler has no problem with the following in
VB:
Select Case x
Case 7
Dim foo As String = a
Case Else
Dim foo As String = b
End Select
Re: If-else vs switch - declaring inner variables (a philosophical question)
Well that is a different problem. You are declaring variables in a way
that is meaningless since they can never really be used anywhere.
Going back to your original... case... I think the real issue is the
apparent inconsistent syntax of the switch statement. I think adding the
braces kind of brings it a little more in line with the rest of the syntax.
But who ever does that :) I suspect it's just a legacy syntax. But, for
the most part, I agree it's a bit strange.
Keep in mind also that in c#, you can't let a case fall through to the next
case.
David
If we can hit that bullseye, the rest of the dominoes
will fall like a house of cards... checkmate!
-Zapp Brannigan, Futurama
On 4 June 2013 13:27, David Burstin david.burs...@gmail.com wrote:
Ok. Brackets will create a closed inner scope. But I am ruminating on the
intricacies of switch vs if-else from a language design point of view. If,
instead of adding brackets to the switch, I remove them from the if-else
and use 2 different variables it is now the if-else that doesn't compile:
if (x == 7)
string foo = a; // Invalid embedded statement
else
string bar = b; // Invalid embedded statement
switch (x)
{
case 7:
string foo = a; // No problems
break;
default:
string bar = b; // No problems
break;
}
As I said, it's a philosophical question - maybe better suited for a
Friday.
Re: Lightweight database
You could try just serialising to xml files. Your powers are strong young Jedi. That's what I'm temporarily doing now, but I'm using the filename as a two-part key like 'jobname#username.xml' which is a bit 1970s! -- Greg
Re: Lightweight database
Not done this myself recently but what about an MDB file? Uneasy about what dependencies it has on other stuff being installed. I'd still have to code a lot of raw ADO and use DataSets or readers and it would get a bit verbose -- Greg
RE: Lightweight database
I think one of the first design parameters you need is how much data. If the amount of data is small, then you can get away with xml. If it starts slowing down you need to move to a different format such as a custom binary. XML - quick to code, easy, the customer can own their own data and work it out themselves if needed. Can be slow as data increases. Binary - slower to code, needs a lot of rules up front, speedy in use, needs custom export as xml functions (perhaps) In both cases you end up loading all the data into memory, so there's a real upper limit. If you get into paging it gets too complex and it's time for a real data provider. XML suffers from having to parse the file, looking for special characters, then a lookup match for each field for each record. Binary on the other hand you can write the length of each record as the record prefix so you just read in chunks of bytes, splitting each field either at fixed length (really quick) or having variable length prefixed with their length. Eg User FirstNameGreg/FirstName LastNameKeogh/LastName User Becomes 30 4 Greg 5 Keogh Where the 30 is the first dword (4 bytes), 4 is the next (4 bytes), then parse the string which is 4 Char (wide is 8 bytes) next 4 bytes is the value of 5, then parse the 5 chars (10 bytes) The problem with doing binary is if they change the schema, it's a real PITA to change the code. |-Original Message- |From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet- |boun...@ozdotnet.com] On Behalf Of Greg Keogh |Sent: Tuesday, 4 June 2013 12:25 PM |To: ozDotNet |Subject: Lightweight database | |Folks, an app has just grown with a new feature that needs to store of users, |jobs and reports and the joins between them, If I was using SQLite it would be |3 tables with joins. However, rather than use SQLite this time I'd like to consider |an alternative that's even more lightweight to setup and use. The app does not |currently use any database technology and the guys managing the project are |actually scared of them. | |Can anyone recommend an in-process database (not necessarily relational!) that |is has a friendly managed API, small footprint, not too complicated and is easy to |get going? I know this is a lot to ask, but there may be some NoSQL options |around that I'm not aware of. The most important issues for me are: (1) Minimal |dependencies (2) Simple managed API. | |I'm running a few web searches now for such things, and I can see Redis, Mongo, |Couch, Raven, db4o, Cassandra, Eloquera, Lucene, and the list goes on and on. |There are too many choices and it would take many days of hard slog to work out |which one would be suitable. So perhaps someone has already been through this |process?! | |I've been tempted many times over the last 10 years to write a pure managed |single-file database with indexes, and nothing much else (no transactions, no |client-server, no schemas, etc). However, I decided to leave it to the experts, and |it looks like there are too many of them, and they all over-engineer their works. | |Cheers, |Greg K
RE: Lightweight database
Agreed. Even with XML, you might to deal with what happens if the schema changes ie: can your new app read an old saved set of data? Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownunder.com I think one of the first design parameters you need is how much data. If the amount of data is small, then you can get away with xml. If it starts slowing down you need to move to a different format such as a custom binary. XML - quick to code, easy, the customer can own their own data and work it out themselves if needed. Can be slow as data increases. Binary - slower to code, needs a lot of rules up front, speedy in use, needs custom export as xml functions (perhaps) In both cases you end up loading all the data into memory, so there's a real upper limit. If you get into paging it gets too complex and it's time for a real data provider. XML suffers from having to parse the file, looking for special characters, then a lookup match for each field for each record. Binary on the other hand you can write the length of each record as the record prefix so you just read in chunks of bytes, splitting each field either at fixed length (really quick) or having variable length prefixed with their length. Eg User FirstNameGreg/FirstName LastNameKeogh/LastName User Becomes 30 4 Greg 5 Keogh Where the 30 is the first dword (4 bytes), 4 is the next (4 bytes), then parse the string which is 4 Char (wide is 8 bytes) next 4 bytes is the value of 5, then parse the 5 chars (10 bytes) The problem with doing binary is if they change the schema, it's a real PITA to change the code. |-Original Message- |From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet- |boun...@ozdotnet.com] On Behalf Of Greg Keogh |Sent: Tuesday, 4 June 2013 12:25 PM |To: ozDotNet |Subject: Lightweight database | |Folks, an app has just grown with a new feature that needs to store of users, |jobs and reports and the joins between them, If I was using SQLite |it would be |3 tables with joins. However, rather than use SQLite this time I'd like |to consider |an alternative that's even more lightweight to setup and use. The app |does not |currently use any database technology and the guys managing the project |are actually scared of them. | |Can anyone recommend an in-process database (not necessarily |relational!) that |is has a friendly managed API, small footprint, not too complicated and |is easy to |get going? I know this is a lot to ask, but there may be some NoSQL |options around that I'm not aware of. The most important issues for me |are: (1) Minimal |dependencies (2) Simple managed API. | |I'm running a few web searches now for such things, and I can see |Redis, Mongo, |Couch, Raven, db4o, Cassandra, Eloquera, Lucene, and the list goes on |and on. |There are too many choices and it would take many days of hard slog to |work out |which one would be suitable. So perhaps someone has already been |through this |process?! | |I've been tempted many times over the last 10 years to write a pure |managed single-file database with indexes, and nothing much else (no |transactions, no |client-server, no schemas, etc). However, I decided to leave it to the experts, and |it looks like there are too many of them, and they all over-engineer |their works. | |Cheers, |Greg K
RE: Lightweight database
Yep, but with XML the new app will read the old data without a problem (unless there has been field delete's or renaming). With the binary, there's a bit more to the coding (and testing) of the layout. That said, if you write the version number in the data file's header, you can switch out to a conversion routine which would use a lot of the old parser anyway. Where-as the XML is a b it harder to switch out to different parsers. So there's probably not a lot in it, but I know it's the binary ones that seem to get me to have get the pad and pen or a spreadsheet open while I do it ;) |-Original Message- |From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet- |boun...@ozdotnet.com] On Behalf Of GregAtGregLowDotCom |Sent: Tuesday, 4 June 2013 2:25 PM |To: 'ozDotNet' |Subject: RE: Lightweight database | |Agreed. Even with XML, you might to deal with what happens if the schema |changes ie: can your new app read an old saved set of data? | |Regards, | |Greg | |Dr Greg Low | |1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax | |SQL Down Under | Web: www.sqldownunder.com | |I think one of the first design parameters you need is how much data. If the |amount of data is small, then you can get away with xml. If it starts slowing down |you need to move to a different format such as a custom binary. | |XML - quick to code, easy, the customer can own their own data and work it out |themselves if needed. Can be slow as data increases. |Binary - slower to code, needs a lot of rules up front, speedy in use, needs custom |export as xml functions (perhaps) | |In both cases you end up loading all the data into memory, so there's a real upper |limit. If you get into paging it gets too complex and it's time for a real data |provider. | |XML suffers from having to parse the file, looking for special characters, then a |lookup match for each field for each record. |Binary on the other hand you can write the length of each record as the record |prefix so you just read in chunks of bytes, splitting each field either at fixed length |(really quick) or having variable length prefixed with their length. |Eg | |User | FirstNameGreg/FirstName |LastNameKeogh/LastName |User | |Becomes | |30 4 Greg 5 Keogh | |Where the 30 is the first dword (4 bytes), 4 is the next (4 bytes), then parse the |string which is 4 Char (wide is 8 bytes) next 4 bytes is the value of 5, then parse |the 5 chars (10 bytes) | |The problem with doing binary is if they change the schema, it's a real PITA to |change the code. | | | ||-Original Message- ||From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet- ||boun...@ozdotnet.com] On Behalf Of Greg Keogh ||Sent: Tuesday, 4 June 2013 12:25 PM ||To: ozDotNet ||Subject: Lightweight database || ||Folks, an app has just grown with a new feature that needs to store of |users, ||jobs and reports and the joins between them, If I was using SQLite ||it |would be ||3 tables with joins. However, rather than use SQLite this time I'd like ||to |consider ||an alternative that's even more lightweight to setup and use. The app ||does |not ||currently use any database technology and the guys managing the project ||are actually scared of them. || ||Can anyone recommend an in-process database (not necessarily ||relational!) |that ||is has a friendly managed API, small footprint, not too complicated and ||is |easy to ||get going? I know this is a lot to ask, but there may be some NoSQL ||options around that I'm not aware of. The most important issues for me ||are: (1) |Minimal ||dependencies (2) Simple managed API. || ||I'm running a few web searches now for such things, and I can see ||Redis, |Mongo, ||Couch, Raven, db4o, Cassandra, Eloquera, Lucene, and the list goes on ||and |on. ||There are too many choices and it would take many days of hard slog to ||work |out ||which one would be suitable. So perhaps someone has already been ||through |this ||process?! || ||I've been tempted many times over the last 10 years to write a pure ||managed single-file database with indexes, and nothing much else (no ||transactions, |no ||client-server, no schemas, etc). However, I decided to leave it to the |experts, and ||it looks like there are too many of them, and they all over-engineer ||their |works. || ||Cheers, ||Greg K | |
Re: If-else vs switch - declaring inner variables (a philosophical question)
It isn't the flow control constructs doing it, it's the scoping.
Possibly the scoping in a for statement is more confusing, but then again,
you can alter its behaviour with a compiler switch.
On Tue, Jun 4, 2013 at 1:27 PM, David Burstin david.burs...@gmail.comwrote:
Ok. Brackets will create a closed inner scope. But I am ruminating on the
intricacies of switch vs if-else from a language design point of view. If,
instead of adding brackets to the switch, I remove them from the if-else
and use 2 different variables it is now the if-else that doesn't compile:
if (x == 7)
string foo = a; // Invalid embedded statement
else
string bar = b; // Invalid embedded statement
switch (x)
{
case 7:
string foo = a; // No problems
break;
default:
string bar = b; // No problems
break;
}
As I said, it's a philosophical question - maybe better suited for a
Friday.
On 4 June 2013 13:09, David Richards ausdot...@davidsuniverse.com wrote:
David,
Try putting braces in:
switch (x)
{
case 7:
{
string foo = a;
break;
}
default:
{
string foo = b; // Compiler not happy because foo
already declared within the switch scope
break;
}
}
David
If we can hit that bullseye, the rest of the dominoes
will fall like a house of cards... checkmate!
-Zapp Brannigan, Futurama
On 4 June 2013 12:15, David Burstin david.burs...@gmail.com wrote:
Hi folks,
I was wondering if someone could explain the logic of the following in
c#:
Using If-Else:
if (x == 7)
{
string foo = a;
}
else
{
string foo = b; // No problem declaring the string
here
}
Using Switch:
switch (x)
{
case 7:
string foo = a;
break;
default:
string foo = b; // Compiler not happy because foo
already declared within the switch scope
break;
}
I understand that the scope for the second example is the entire switch
statement, but why does that need to be the case (pardon the pun)? Is it
just because of the ability to fall through from one case statement to the
next (by omitting the break)?
Just as a comparison, the compiler has no problem with the following in
VB:
Select Case x
Case 7
Dim foo As String = a
Case Else
Dim foo As String = b
End Select
--
Meski
http://courteous.ly/aAOZcv
Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough - Adam Hills
RE: Lightweight database
Yep, that's what I was getting at. The object structure might change between versions. Extra columns won't be an issue but other sorts of changes probably would be. Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownunder.com Yep, but with XML the new app will read the old data without a problem (unless there has been field delete's or renaming). With the binary, there's a bit more to the coding (and testing) of the layout. That said, if you write the version number in the data file's header, you can switch out to a conversion routine which would use a lot of the old parser anyway. Where-as the XML is a b it harder to switch out to different parsers. So there's probably not a lot in it, but I know it's the binary ones that seem to get me to have get the pad and pen or a spreadsheet open while I do it ;) |-Original Message- |From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet- |boun...@ozdotnet.com] On Behalf Of GregAtGregLowDotCom |Sent: Tuesday, 4 June 2013 2:25 PM |To: 'ozDotNet' |Subject: RE: Lightweight database | |Agreed. Even with XML, you might to deal with what happens if the |schema changes ie: can your new app read an old saved set of data? | |Regards, | |Greg | |Dr Greg Low | |1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 |4913 fax | |SQL Down Under | Web: www.sqldownunder.com | |I think one of the first design parameters you need is how much data. |If the |amount of data is small, then you can get away with xml. If it starts slowing down |you need to move to a different format such as a custom binary. | |XML - quick to code, easy, the customer can own their own data and work |it out |themselves if needed. Can be slow as data increases. |Binary - slower to code, needs a lot of rules up front, speedy in use, needs custom |export as xml functions (perhaps) | |In both cases you end up loading all the data into memory, so there's a real upper |limit. If you get into paging it gets too complex and it's time for a |real data |provider. | |XML suffers from having to parse the file, looking for special |characters, then a |lookup match for each field for each record. |Binary on the other hand you can write the length of each record as the record |prefix so you just read in chunks of bytes, splitting each field either |at fixed length |(really quick) or having variable length prefixed with their length. |Eg | |User | FirstNameGreg/FirstName |LastNameKeogh/LastName |User | |Becomes | |30 4 Greg 5 Keogh | |Where the 30 is the first dword (4 bytes), 4 is the next (4 bytes), |then parse the |string which is 4 Char (wide is 8 bytes) next 4 bytes is the value of |5, then parse |the 5 chars (10 bytes) | |The problem with doing binary is if they change the schema, it's a real PITA to |change the code. | | | ||-Original Message- ||From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet- ||boun...@ozdotnet.com] On Behalf Of Greg Keogh ||Sent: Tuesday, 4 June 2013 12:25 PM ||To: ozDotNet ||Subject: Lightweight database || ||Folks, an app has just grown with a new feature that needs to store ||of |users, ||jobs and reports and the joins between them, If I was using SQLite ||it |would be ||3 tables with joins. However, rather than use SQLite this time I'd ||like to |consider ||an alternative that's even more lightweight to setup and use. The app ||does |not ||currently use any database technology and the guys managing the ||project are actually scared of them. || ||Can anyone recommend an in-process database (not necessarily ||relational!) |that ||is has a friendly managed API, small footprint, not too complicated ||and is |easy to ||get going? I know this is a lot to ask, but there may be some NoSQL ||options around that I'm not aware of. The most important issues for me ||are: (1) |Minimal ||dependencies (2) Simple managed API. || ||I'm running a few web searches now for such things, and I can see ||Redis, |Mongo, ||Couch, Raven, db4o, Cassandra, Eloquera, Lucene, and the list goes on ||and |on. ||There are too many choices and it would take many days of hard slog to ||work |out ||which one would be suitable. So perhaps someone has already been ||through |this ||process?! || ||I've been tempted many times over the last 10 years to write a pure ||managed single-file database with indexes, and nothing much else (no ||transactions, |no ||client-server, no schemas, etc). However, I decided to leave it to the |experts, and ||it looks like there are too many of them, and they all over-engineer ||their |works. || ||Cheers, ||Greg K | |
Re: If-else vs switch - declaring inner variables (a philosophical question)
On 4 June 2013 15:08, mike smith meski...@gmail.com wrote: It isn't the flow control constructs doing it, it's the scoping. Agreed. It is quite clear when there is 'explicit' scoping (curly brackets), but there is also 'implied' scoping (eg a single line after an if). Why can't a useless variable be declared after an if without braces, but is ok if we wrap that single line in a pair of curlies?
Re: If-else vs switch - declaring inner variables (a philosophical question)
On Tue, Jun 4, 2013 at 3:22 PM, David Burstin david.burs...@gmail.comwrote: On 4 June 2013 15:08, mike smith meski...@gmail.com wrote: It isn't the flow control constructs doing it, it's the scoping. Agreed. It is quite clear when there is 'explicit' scoping (curly brackets), but there is also 'implied' scoping (eg a single line after an if). Why can't a useless variable be declared after an if without braces, but is ok if we wrap that single line in a pair of curlies? It's easier (for maintainers) to explicitly scope it with unnecessary curlies than rely on implicit. Our internal coding rules mandate stuff like that :) Which didn't really answer that question, either. -- Meski http://courteous.ly/aAOZcv Going to Starbucks for coffee is like going to prison for sex. Sure, you'll get it, but it's going to be rough - Adam Hills
Re: If-else vs switch - declaring inner variables (a philosophical question)
You've basically asked about C#'s scoping rules. Eric Lippert has answered
this question a few times, here he is talking about it on StackOverflow:
http://stackoverflow.com/a/2050864
Typically the C# designers lent on the side of explicitness where the
compiler might do something you didn't expect. In this case, if you declare
a variable with the same name in two different switch cases, should you be
able to refer to it outside the select? Is it two variables, or different
initializations of the same one? What if they differ by type? What happen
if one of the cases doesn't declare the variable? And (more relevantly) how
much effort does the compiler (and language designers) have to put into
thinking about the edge cases, vs just not allowing it in the first place
(and implementing something more useful instead)?
On 4 Jun 2013 10:16, David Burstin david.burs...@gmail.com wrote:
Hi folks,
I was wondering if someone could explain the logic of the following in c#:
Using If-Else:
if (x == 7)
{
string foo = a;
}
else
{
string foo = b; // No problem declaring the string here
}
Using Switch:
switch (x)
{
case 7:
string foo = a;
break;
default:
string foo = b; // Compiler not happy because foo
already declared within the switch scope
break;
}
I understand that the scope for the second example is the entire switch
statement, but why does that need to be the case (pardon the pun)? Is it
just because of the ability to fall through from one case statement to the
next (by omitting the break)?
Just as a comparison, the compiler has no problem with the following in VB:
Select Case x
Case 7
Dim foo As String = a
Case Else
Dim foo As String = b
End Select
