My research so far indicates:
1) A recipe manager should work well with pocket computers, so you can take your grocery list to the store.
2) It should have a huge recipe database and be able to import meal master and other common recipe file formats.
3) It should have a conduit so the heavy data entry is done on a PC with a full keyboard
4) It should print a nice recipe on paper– use that one in the kitchen and keep your palm away from the kitchen where it could fall in the soup.
5) Pocket cook is looking good right now… To get the grocery lists to work, you need to also install Handyshopper (pocket cook exports to handyshopper)
I’m going to try these out this Thanksgiving and see if they transform my life or not.
Possible killer app here: password databases. I’ll know in 30 days if I can’t live without a password database. The winning feature so far is that the passwords can be edited on the PC and the palm, also the screens stop showing the passwords after a predefined time.
I’ve been doing my best to kill my SanDisk, no death yet.
My Tungsten T3 is already so fast, I’m not sure if it is worth overclocking it, in fact it might be worth it to slow some applications down.
I’m not sure how to use this feature, but I’ve notice that once you put stuff into a palm, it keeps showing up for years (the synch software is very reluctant to permanently get rid of stuff) This ties in with the password issue. A palm would be a good place to put passwords: encrypted and they are more retrievable than post it notes.
Ideally, we want to have a function that will drop a table if it exists, do nothing if it doesn’t exist. This can be done in T-SQL or DTS. In DTS we create a single DROP TABLE statement into SQL task and then have the exit arrow set to ‘on completion’ so the code goes on even if the table didn’t exist. This can create a lot of clutter on the DTS drawing board.
Writing pure T-SQL makes this a pain, but with a T-SQL function, at least you can shorten the code.
IF dbo.TableExists('myTable')=1 -- THEN
drop table myTable
-- END IF
The DDL for the above function is :
FUNCTION dbo.TableExists(@tableName varchar(250))
DECLARE @OUT bit
IF EXISTS(SELECT TABLE_NAME FROM DATA.INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = LTRIM(RTRIM(@tablename)))
SET @OUT = 1
SET @OUT = 0
The database name needs to be changed for each database where the function is deployed. Also, notice I’m returning a bit and not a boolean, (which I’m not sure if it is possible), so you have to check for equality to 1 or 0 when using the function.
Can handle a lot of data (unless you are using MDBE)
Some DDL chores are easier in access than enterprise manager
Gives a MS-Access front end to SQL6.5
TSQL is a more expressive SQL dialect than JET SQL
Hard to use VBScript functions, VB functions can’t be called from inside a stored procedure.
Impossible to figure out how to change connection timeout
Impossible to figure out how to globally turn off the ‘rowcount 10000′ feature.
On account of the previous 2 problems I run almost all of my queries in Query Analyzer
Requires extra step to graphically update joined tables
Screws up the formatting of TSQL– default formatting isn’t very readable
Can’t graphically view common constructs like CASE/WHEN/THEN
Defaults to creating a table valued function instead of a stored procedure
Have to split data accross lots of tables if you are using MSDE
Heterogenous joins between local and linked tables have lousy performance (as compared to joining local tables to linked tables in an Access .mdb)
Linked tables have cumbersome names, like SERVER_DATABASE_DBO_TABLENAME, which is a pain when the “SERVER_DATABASE_DBO_” part never changes! Why couldn’t they have used a shorter alias?
Can’t see date/time a table or procedure was created (although the data can be seen in enterprise manager!)
To graphically update the join of 2 tables, create a view and then update the view.