PDA

View Full Version : login with NthTableLogOnServer in subreports



Marcello lima
11-May-2005, 08:57 AM
i needing to log in subreports, and found this post of Edgar Briney, but the commands what he used to do this (such as "NthTableLogOnServerNameSubReports" and others) do not exist, anybody already have done this ? this methods exists in CRPE32.DLL ?



regards,

Marcello Lima

marcello@prosoftware.com.br



------------------------------------------------------------------------------------------------------







Your working to hard. Look at this Code. The way it works if it's a Dataflex Report I set the Location or if it's a client server database Just Log on. The Sub Report logic is base off of C Code sent to me by one of Segate Tech.

Edgar

"Barry Munro" <baz@peace-of-mind.com.au> wrote in message news:42C6A0622380D31188C30000E85123F55C6FE7@EMAILE R...
Tina,
if I'm reading your post correctly, you are having problems:
writing / editing reports off site,
then bringing them on to site and altering their connection(s) for use?

Use ODBC as your connection type, and trusted_connections,
be sure that each client has the latest p2sodbc.dll in:
W98SE - \system
W2K Pro - \system32.
Use a small installer like MakeNSIS to push it out with during installs / re-installs of your app.
Create a system DSN on each client box with a 'common' name, choose client configuration type, and then UNCHECK all the boxes except for the default database - which will of course, be your database of interest. If the database was made the Default for this user group in EM - no need.
The MS staffers in the microsoft.public.sqlserver.odbc newsgroup suggest building one on a client box, then export the reg. key out, for use on all like client OS's - if you cannot physically attend to each.
Push this reg. key out with your little installer . . .

Back in your dungeon, create an ODBC system DSN against the test database, with the 'common' name.
Write / edit the report(s).
Send 'em out to site, by email, CD, flaptop, whatever, and plug them in.
I have not found this needed yet myself, but is a tip from the Crystal newsgroup for nasty connections where the database will only ever have ONE owner's data:
When you have finished your report off site, before leaving it, go to Set Locations, try removing the ServerName.dbo. from the front of each table, both in the main report & it's subreports.
In ODBC, the ServerName is really the DSN name. You could call it anything.
But be careful, visualise your help desk telling a client:
" . . go to the Data Sources (ODBC) applet, create a system DSN, call it Anything, now select the server named . . "

If you are not using trusted_connections, ignore this - keep looking for answers, ODBC will still work - is just harder.
Apart from the obvious need for a connection type of some sort, you are really just dealing with access permissions.
HTH, Baz.