Iphone

I have decided to change my MDB Access front-end to an Access project. However some things seems to work different:

1) I have a form that on the Load event it would do something like this:
Me.Recordsource = "Select ID, Name, Etc from tblSample"
I am not able o add records if I use this method.

2) I am not able to pass variables to SQL strings to fill textboxes like:
list1.recordsource = "Select WorkDays from tblSample2 Where ((Workdays > [txtBeginDate]))"
I get an error saying that [txtBeginDate] is not a column.

3) I had a function to calculate WorkDays that used "Weekday" in its coding. Now I get an error saying that "Weekday" is not a bult-in function.

Thanks in advance for your help.

Iphone

You're finding just some of the issues that are inherent to upsizing.
Just mention only the issues you've found so far (there *will* be other's if you're committed to this process)...

1) If it's a straight forward Select statement you should still be able to assign the source thusly.
The upsizing process itself may have left your tables in a state where they're not appendable.
Can you open the table directly through the Access database window and add records there?
You need to be sure the table has a Primary key (still) and that default values are specified for fields (especially any bit fields).

2) Nope - you can't pass parameters as you'd have once had.
The local textbox is meaningless to SQL Server. You'll have to assign it as
list1.recordsource = "Select WorkDays from tblSample2 Where ((Workdays > '" & Me.[txtBeginDate] & "'))"

3) Indeed - Jet's functions (and the functions it shares with VBA) are also without meaning in T-SQL.
(T-SQL is SQL Server's SQL language - and in an ADP everything needs to be in that dialect).
You'll need to abide by functions that are supported on the server. You could try the DAY function instead as a quick attempt.

In an ADP there is no local database engine anymore (Jet isn't there to help you). Everything is executed on the server.
If you use an MDB with linked tables the process is perhaps more gentle (though *very* likely not as efficient).
But you could perhaps work up to a fully OLEDB solution then.